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This  research  considers  the  “Seastar”  concept  of  an  underwater  local-area  network 
(LAN)  having  a  central  node  and  multiple  peripheral  nodes.  The  concept  of  operation  for 
the  Seastar  LAN  involves  the  delivery  of  large  volumes  of  digital  information  from  the 
peripheral  nodes  through  direct  acoustic  communication  links  to  a  sophisticated  central 
node  for  assimilation  (e.g.,  beamforming,  fusion).  For  a  design  range  of  500  meters,  link 
budget  analysis  in  combination  with  parametric  analysis  evaluates  physical-layer 
parameters  including  optimum  carrier  frequency,  spectral  bandwidth,  modulation 
techniques,  achievable  bit  rate,  and  energy  budget.  Performance  data  obtained  from  a 
prototype  Seastar  LAN  constructed  from  existing  acoustic  modems  guided  the  creation  of 
a  Seastar  numerical  simulation.  Monte  Carlo  simulation  studies  examine  the  relative 
merits  of  networking  strategies  such  as  TDMA  polling  and  token-based  TDMA.  Seastar 
is  shown  to  meet  the  anticipated  requirements  for  undersea  LAN  applications  such  as 
sensor  networks,  undersea  vehicle  swarms,  and  dive  teams. 
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I.  INTRODUCTION 


The  Seaweb  wide-area  network  (WAN)  concept  [1]  provides  for  local-area 
networks  (LANs)  having  a  sophisticated  central  node  that  collects  and  fuses  undersea 
data  from  a  set  of  relatively  simple  peripheral  nodes,  as  illustrated  in  Figure  1. 


Figure  1  Left:  The  Seastar  concept  involves  asymmetric,  centralized  topologies. 
Relatively  simple  peripheral  nodes  (red)  report  time-series  data  at  high-bit-rates  to 
sophisticated  central  nodes  (green),  where  data  fusion  is  performed  for  the  local 
area.  Peripheral  nodes  may  receive  low-bit-rate  utility  packets  from  the  central 
node  and  from  their  peers.  Right:  Wide-area  communications  (green  links) 
between  central  nodes  and  theater  communications  through  gateway  nodes  occur 
via  Seaweb  networking  in  a  lower  band  of  the  acoustic  spectrum. 

In  more  general  terms,  localized  clusters  of  nodes  (e.g.,  sensors,  crawlers,  divers) 
assimilate  as  subnets  through  the  formation  of  LANs,  each  containing  a  central  node  and 
peripheral  nodes  distributed  in  an  undersea  region  up  to  one  square  kilometer  (km  ).  The 
Seaweb  LAN  with  centralized,  or  star,  topology  is  called  “Seastar”  and  is  motivated  by 
the  desire  for  an  additional  tier  of  local-area  communications  compatible  with  and 
complementary  to  Seaweb  wide-area  acoustic  communications.  The  Seastar  tier  uses  a 
higher-frequency  portion  of  the  acoustic  spectrum  made  possible  by  shorter 
communication  ranges  and  necessitated  by  the  high  throughput  of  the  LAN.  The  baseline 
Seastar  topology  is  centralized,  with  axial  asymmetry  and  peer-to-peer  capability. 
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A. 


SCOPE 


This  thesis  explores  candidate  Seastar  networking  strategies  and  considers 
physical-layer  and  link-layer  attributes.  The  effects  of  the  underwater  communications 
channel  on  carrier  frequency,  signal  bandwidth,  capacity  and  energy  budget  are  studied 
and  tradeoffs  regarding  modulation  type,  access  method  and  topology  are  presented.  In 
order  to  investigate  the  feasibility  of  an  underwater  acoustic  LAN,  a  Seastar  prototype 
was  developed  and  tests  were  conducted  both  in  air  and  in  water.  The  experimental 
results  provide  useful  information  for  design  purposes  and  form  the  basis  of  a  network 
simulation  that  was  developed  as  part  of  this  research.  The  simulation  is  used  to  study 
different  network  strategies  under  various  conditions  and  to  perform  case  studies  that  are 
included  in  this  document.  In  summary,  this  thesis  provides  tradeoffs  that  allow  both 
designers  and  operational  users  to  validate  the  possibilities  and  limitations  of  the  Seastar 
concept. 


Figure  2  Seastar  applications  include  sensor  arrays,  sensor  clusters,  unmanned  undersea 

vehicle  formations,  and  dive  teams. 

The  broad  scope  of  the  research  topic  requires  judicious  restrictions  in  the 
research  that  was  conducted.  Throughout  this  study  a  fixed  communication  range  of  500 
meters  (m)  is  considered.  Propagation  is  generally  assumed  to  occur  along  a  direct  path  in 
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a  homogeneous  (constant  speed  of  sound)  environment.  The  use  of  mobile 
communication  nodes  is  excluded  in  simulations  and  experiments  but  included  in 
discussions.  Issues  such  as  interference  between  adjacent  Seastar  clusters  and  integration 
of  Seastar  and  Seaweb  need  to  be  studied,  but  are  beyond  the  scope  of  this  thesis. 

B.  APPROACH  AND  STRUCTURE 

The  topic  of  acoustic  communications  brings  two  communities  together 
(communication  theory  and  underwater  acoustics),  each  using  their  own  language.  The 
literature  on  this  topic  is  not  always  consistent  in  translating  the  terminology  of  the 
communications  discipline  and  the  acoustics  discipline. 

Chapter  II  adopts  the  conventions  of  the  underwater  acoustician  to  discuss  the 
physical  properties  of  the  underwater  communications  channel,  and  derive  an  expression 
for  the  acoustic  signal-to-noise  power  ratio  and  corresponding  sonar  equation.  A  link 
budget  analysis  is  performed  for  conditions  under  which  Seastar  is  anticipated  to  operate 
with  the  purpose  of  determining  an  optimum  carrier  frequency. 

Chapter  III  discusses  the  physical  layer  of  Seastar  and  contains  a  case  study  to 
provide  the  reader  with  some  hardware,  bandwidth,  capacity  and  energy  budget 
considerations.  The  central  part  of  Chapter  III  contains  a  study  on  modulation  techniques. 

Chapter  IV  brings  us  deeper  into  network  theory  and  suggests  several  network 
topologies.  It  discusses  variations  in  access  to  the  medium  and  studies  control  of 
information  flow.  The  chapter  ends  with  an  outline  of  experiments  that  resulted  in  the 
development  of  the  first  Seastar  prototype. 

Chapter  V  leads  the  reader  further  into  the  prototype  analysis  by  providing  an 
overview  of  network  performance  results  as  obtained  during  an  in-water  deployment  in 
St.  Andrews  Bay,  FL.  The  results  of  these  experiments  were  used  to  develop  a  network 
simulation  tool  that  provides  us  with  data  regarding  the  performance  of  other  network 
strategies  that  could  not  easily  be  implemented  and  tested  with  existing  hardware. 

Chapters  VI  and  VII  show  the  setup  of  the  simulation  and  display  parametric 
results  allowing  a  better  view  on  Seastar  possibilities  and  limitations. 
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Finally,  since  an  optimal  Seastar  strategy  depends  on  the  networks’  purpose,  three 
case  studies  are  performed  to  provide  operational  end-users  with  some  ideas  that  may 
help  shape  future  applications  for  Seastar.  These  case  studies  illustrate  the  conclusions 
stated  in  Chapter  VIII. 
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II.  THE  COMMUNICATION  CHANNEL 


An  important  characteristic  of  the  underwater  acoustic  communication  channel  is 
the  dependence  of  path  loss  and  ambient  noise  on  communication  distance  and 
transmission  frequency.  This,  therefore,  affects  other  communication  parameters  like 
signal  bandwidth  and  data  rate.  In  this  chapter  we  look  at  the  influence  that  the 
environment  has  on  the  signal  that  is  transmitted  and  from  this  we  will  determine  the 
optimum  carrier  frequency  and  bandwidth  to  use.  We  will  limit  our  analytical  scope  to 
path  loss  and  ambient  noise,  but  the  effects  of  multi-path  propagation  and  single -path 
fluctuations  will  be  briefly  discussed  when  analyzing  appropriate  waveforms. 

A.  THE  PHYSICAL  CHANNEL 

The  underwater  communication  channel  can  be  described  as  a  cylindrical 
waveguide  that  is  bounded  by  the  sea  surface  and  the  sea  floor  with  communication 
ranges  generally  exceeding  water  depth.  Variations  in  channel  composition,  depth  and 
temperature  cause  refraction  of  sound,  often  combined  with  surface  and  bottom 
reflections  and  convolutions  with  imparted  boundary  conditions,  resulting  in  a  multitude 
of  possible  propagation  paths  for  communication  signals.  Each  single  path  imposes 
temporal,  spatial  and  frequency-dependent  amplitude  and  phase  fluctuations  on  a 
waveform.  The  accumulation  of  these  paths  at  the  receiver  produces  multi-path  reception 
replete  with  distortion,  and  dispersion  of  the  waveform.  These  deleterious  effects 
translate  into  fading,  inter-symbol  interference,  and  loss  of  coherence. 

B.  ACOUSTIC  SIGNAL-TO-NOISE  POWER  RATIO 

The  sometimes  inconsistent  use  of  terminology  in  the  interdisciplinary  field  of 
underwater  acoustic  communications  by  the  technical  communications  community  [2-4] 
and  underwater  acoustics  community  [5-7]  creates  confusion,  and  forms  the  motivation 
for  deriving  some  important  expressions  in  generally  accepted  acoustic  terms.  This  will 


be  done  in  accordance  with  [8-9].  To  analyze  the  communication  losses  through  the 
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channel  we  will  introduce  the  term  acoustic  signal-to-noise  power  ratio  SNRa  at  the 
receiver  which  is  defined  as  follows  [9]: 


SNR. 


(2.1) 


where  ps(t, ri)  and  pn(t, ri)  are  the  acoustic  pressures  due  to  signal  and  noise,  respectively, 
incident  upon  a  receiver  located  at  ri=(xi,yi,zi),  and  £{•}  is  the  expected  value.  The  SNRa 
informs  us  on  the  status  of  the  transmission  at  the  input  to  the  receiver  before  the  signal  is 
processed. 


1.  Signal 


A  communications  signal  in  an  underwater  acoustic  channel  usually  consists  of  a 
band  of  frequencies.  Therefore,  in  order  to  derive  an  equation  for  SNRa  that  is  equivalent 
to  the  “narrowband”  signal-to-noise  ratio  equation  in  [2],  the  time -harmonic  acoustic 
pressure  at  time  t  in  seconds  (s)  and  range  ro,  i  in  meters  (m)  from  the  source  (see  Figure 
3)  can  be  expressed  as: 

Ps  (t’ri )  =  I Pf.s  (r!  )|cos  faft  +  zPf,s  (r, ))  (2.2) 


where,  (e.g.  see  [10]) 


Pf.s  (ri  )  =  Po 


e~a(f)(r0i-R)  e~jk(r0i-R) 


(2.3) 


Po=\Po\e+jZp°  (2-4) 

is  the  spatial-dependent  part  of  the  time-harmonic  acoustic  pressure  in  Pascals  (Pa)  at  one 
meter  from  the  source  and  a(f)  is  the  frequency-dependent  attenuation  coefficient  in 
Nepers  per  meter  (Np/m).  We  assume  that  the  signal  sound  source  is  a  motionless,  time- 
harmonic,  omnidirectional  point  source  and  that  the  medium  is  unbounded  and  viscous 
with  a  constant  speed  of  sound,  and  R=  1  m  is  the  reference  range  from  the  source. 
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Figure  3  Source  (ro)  -  receiver  (iq)  geometry  where  R  =  1  m  is  the  reference  range 

from  the  source. 


Substitution  of  Po=\po\  into  (2.4)  and  computing  the  magnitude  of  (2.3)  yields 

\p,„M\  =  PAeM,tr’‘-R). 

ro.i 


(2.5) 


If  we  treat  ps(t,r i)  as  being  deterministic  and  since  it  is  also  periodic,  we  can  replace  the 
numerator  of  (2.1)  with  the  time- average  power 


Ps  (M-i)f)  =  7 \\p,  (Mi)|2  dt  =  \\pf,s  (ri)|2  • 


(2.6) 


Substituting  (2.5)  into  (2.6)  gives  the  following  equation: 


Ps{t>T i)f)  = 


v2  °  r°-i  J 


-2  «(/)('bj-s)  2  /  \ 

"rms^s  VA1  / 


(2.7) 


where  p„ns,s(r 0  >s  the  root-mean  square  value  of  the  acoustic  pressure  of  the  signal  in  Pa 
at  a  receiver  at  position  iq  that  was  transmitted  omnidirectionally  by  a  source  at  position 

ro. 


2.  Noise 

Noise  in  the  ocean  is  generated  by  various  sources  such  as  wind,  shipping  and 
flow  noise.  To  come  up  with  a  general  expression  for  the  average  power  of  the  acoustic 
pressure  that  is  created  by  the  noise  and  received  by  the  receiver  at  iq,  we  assume  that 
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pn(t, ri)  is  a  zero  mean,  wide-sense  stationary  (WSS),  random  process,  representing  an 
arbitrary  function  of  time.  As  a  result,  the  autocorrelation  function  of  the  noise  can  be 
expressed  as  follows: 

Rp  ( t , t\ rt )  =  Rp  (t  - 1', )  =  Rp  (At, r , )  =  E{pn ( t , r, ) /? * (t\ r, )}  (2.8) 

Since  Rp  ( A/ .  r, )  forms  a  Fourier  transform  pair  with  its  power  spectral  density  function 
Sp  (/7,rj)in  Pa~/Hz,  the  average  power  of  the  zero  mean,  WSS  noise  is  given  by  the 
following  relation: 

<  (r1)  =  fi,,(0)  =  £{|p,«,r1)|;}=  j  Sp-(lJ,rtylj)  (2.9) 


where  <J2p  (r,)  is  the  noise  variance  and  ;/  represents  frequency  in  hertz  (Hz).  If  we 


consider  a  limited  noise  bandwidth  of  A f  centered  around  frequency  /,  and  taking  into 
account  that  the  power  spectrum  is  an  even  function  of  frequency,  we  obtain  the 
following  expression  for  the  denominator  of  (2.1): 


This  general  expression  for  the  average  power  of  the  noise  can  easily  be  converted  to  a 
noise  level  by  letting  A/  =1  Hz.  Substituting  (2.7)  into  the  numerator  of  (2.1)  and  (2.9) 
into  the  denominator  of  (2.1)  yields: 


SNR ,  = 


to 


<to 


f  p2  A 
rref 

p 2 

ivy 


4lPJ2  r 

_  V  Kef  r0.1  J 

r2Sp  (/,r,)A/^ 


-2  ff(/)(r01-R) 


(2.11) 


v  ref  J 

where  Pref= 1  pPa  is  the  root-mean- square  reference  pressure  amplitude. 


The  last  step  is  to  express  (2.11)  in  decibels  (dB)  and  set  the  reference  range  R  to 
1  m.  Doing  so  yields  an  expression  for  SNRa  (in  dB)  as  shown  in  (2.12)  in  more  familiar 
terms;  namely,  source  level  ( SL ),  noise  level  (NL)  and  transmission  loss  (TL),  where 
transmission  loss  consists  of  a  spherical  spreading  term  and  a  frequency-dependent 
attenuation  term: 

SNRa  (in  dB)  =  SL-  NL  -  TL  (2.12) 
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where 


SNRa{ in  dB)  =  101og wSNRa 

f  u\ 


SL  =  201og1() 

f 


42Pj2 

V  P™f  J 


dB  re  P 


NL  =  lOlog 
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2SJ/,r1)A/ 


ref 


dB  re  P^ 


(2.13) 

(2.14) 

(2.15) 


TL  =  201og10(r0 4)  +  a\f)(r0^  -1)  dB  re  Pref  (2.16) 

and  a'(f)  =  S.6S6a(f)  where  oc'(f)  is  in  dB/m  and  a(f)  is  in  Np/m.  We  will  use 
analytical  expressions  based  on  empirical  data  for  a'(f)  and  Sp  (/, r,) ,  in  order  to  allow 

us  to  perform  the  next  step  in  analyzing  underwater  acoustic  communications.  We  will  do 
this  by  performing  a  link  budget  analysis,  a  method  that  was  described  by  Hansen  [11] 
and  proved  to  be  viable  in  the  underwater  environment. 


C.  LINK  BUDGET  ANALYSIS 


1.  Transmission  Loss 

Spherical  spreading  and  frequency-dependent  attenuation  are  the  two  components 
of  transmission  loss  (TL)  in  (2.16).  Some  of  the  literature  (e.g.,  see  [1])  expresses  the 
spreading  component  201og10(r01)  in  the  form  of  kl01og10(r01) ,  l<k<2,where  k  =  1  is 

used  for  cylindrical  spreading,  k  =  2  for  spherical  spreading  and  k  =  1 .5  for  the  so  called 
practical  spreading.  This  may  result  in  severe  under-  or  overestimation.  Although  it  is 
recognized  that  physics-based  modeling  of  multi-path  propagation  is  more  realistic  and 
provides  a  more  accurate  representation  of  the  losses  in  the  channel,  the  choice  has  been 
made  to  use  the  spherical  spreading  direct  path  model. 

Various  empirical  formulas  for  the  attenuation  coefficient  cc'(f)  can  be  found  in 
the  open  literature.  The  empirical  formula  provided  by  Francois  and  Garrison  [12,  13]  is 
claimed  by  them  to  apply  to  all  oceanic  conditions  and  frequencies  from  200  Hz  to  1 
megahertz  (MHz)  with  an  estimated  accuracy  of  5%  and  appears  to  embrace  and  improve 
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upon  the  studies  conducted  by  Thorp  [14],  Fisher  and  Simmons  [15],  and  Marsh  and 
Schulkin  [16].  Since  we  anticipate  using  carrier  frequencies  between  20  and  100  kilohertz 
(kHz),  we  will  use  the  formula  in  Francois  and  Garrison  [12,  13]  for  the  attenuation 
coefficient.  Figure  4  shows  two  examples  of  frequency  dependency  of  the  attenuation 
coefficient  expressed  in  dB/km  for  two  different  temperatures,  T  =  14  C  and  T  =  20  C° , 
salinity  S  =  35  parts  per  thousand  (ppt),  acidity  pH  =8.0  and  depth  D  =  50  m  . 


Figure  4  Attenuation  coefficient  a\f)  in  dB/km  versus  frequency  in  kHz  based  on 
Francois  and  Garrison  [12,  13]  for  the  above  described  conditions. 


It  is  clear  that  the  attenuation  coefficient  increases  with  frequency,  but  since  we 
consider  a  maximum  transmission  range  of  500  m  for  Seastar,  the  question  arises  at  what 
frequency  will  the  attenuation  coefficient  start  to  gain  influence  compared  to  spherical 
spreading. 
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Figure  5  indicates  that  the  impact  of  frequency-dependent  attenuation  at  500  m  is 
insignificant  up  to  approximately  25  kHz,  but  adds  7  dB  to  the  TL  at  50  kHz.  Beyond  50 
kHz  the  influence  of  attenuation  increases  quickly.  Increasing  the  carrier  frequency  and 
signal  bandwidth  therefore  comes  at  the  cost  of  range  reduction. 


Figure  5  Relative  influence  of  losses  caused  by  frequency-dependent  attenuation  on 
total  transmission  loss  in  dB  (vertical  axis)  for  different  ranges  in  m  (horizontal 
axis).  For  a  range  of  500  m,  losses  due  to  attenuation  are  of  minor  importance  for 
frequencies  below  25  kHz  compared  to  losses  due  to  spherical  spreading. 


2.  Noise  Level 

The  next  factor  in  (2.12)  that  needs  to  be  addressed  is  the  noise  level  given  by 
(2.15).  If  we  consider  future  Seastar  deployment  without  defining  geographic  restrictions 
we  learn  [5,  6,  17]  that  underwater  noise  in  general  contains  several  contributors  that  each 
affect  different  frequency  bands  and  that  can  be  described  empirically.  Comparisons  for 
different  situations  [6]  show  that  different  oceanographic  conditions,  such  as  water  depth 
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and  temperature,  do  influence  the  appearance  of  noise  but  that  the  empirical  formulas  [5] 
satisfy  a  description  for  noise  in  the  most  general  case.  Noise  measurements  are  also 
reported  as  noise  spectrum  levels  ( NSL )  in  dB  with  reference  to  1  pPa2/Hz  (e.g.,  see  [10]) 


NSL  =  10  log 
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(2.17) 


v  pPa  /Hz 

The  NSL  in  dB  based  on  empirical  formulas  by  Coates  [5]  is  generally  dependent  on  four 
sources  dominating  certain  frequency  bands,  namely  turbulence  (<10  Hz),  shipping  (10- 
200  Hz),  wind  (0.2-100  kHz)  and  thermal  activity  (>100  kHz).  Figure  6  indicates  that  the 
NSL  for  the  frequency  band  between  1-100  kHz  that  is  typically  used  for  underwater 
communications  is  mainly  due  to  wind. 


Figure  6  The  noise  spectrum  level  (NSL)  in  dB  based  on  empirical  formulas  by  Coates 

[5]. 


Figure  7  demonstrates  that  the  wind  speed  has  a  profound  effect  on  the  value  of 
the  NSL. 
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Figure  7  Increase  of  wind  speed  has  a  profound  effect  on  the  noise  spectrum  level. 

Based  on  empirical  formulas  by  Coates  [5], 


3.  Optimum  Carrier  Frequency  as  a  Function  of  Range 

Combining  TL  and  NL  for  a  wind  speed  of  5  meters  per  second  (m/s)  results  in 
Figure  8,  where  —  {TL  +  NL)  is  plotted  so  that  the  red-yellow  region  indicates  favorable 
transmission  conditions.  For  the  maximum  anticipated  range  of  500  m,  small  negative 
values  for  -(TL  +  NL)  can  be  observed  somewhere  between  30-50  kHz.  In  order  to 

determine  an  exact  minimum,  a  slice  at  500  m  is  taken  from  Figure  8  and  plotted  for 
various  wind  speeds  and  medium  shipping  density,  resulting  in  Figure  9. 
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Figure  8  Effect  of  frequency  and  range  on  transmission  loss  and  noise  level  (dB  re  1 

qPa). 


Table  1  shows  the  frequencies  at  which  the  minimum  TL+NL  are  found  for 
various  wind  speeds  and  seawater  temperatures  with  medium  shipping  density,  a  salinity 
of  35  ppt  and  a  water  depth  of  50  m.  The  last  column  shows  the  frequencies  for  various 
wind  speeds  when  averaged  over  sea  water  temperature.  These  averages  are  taken  to  be 
representative  of  “typical”  values.  It  is  obvious  from  Table  1  that  the  minimum  value  for 
TL  +  NL  depends  for  a  large  amount  on  wind  speed  and  to  a  lesser  extent  on  sea  water 
temperature.  Other  factors,  like  shipping  density  or  water  depth,  have  no  significant 
influence. 


8°C 

14°C 

20°C 

26°C 

Average 

0  m/s 

28.3 

29.0 

30.1 

31.4 

29.7 

5  m/s 

39.3 

38.9 

41.1 

44.3 

40.9 

10  m/s 

40.3 

39.6 

41.8 

45.3 

41.8 

15  m/s 

40.5 

39.7 

42.0 

45.6 

42.0 

Table  1  Frequency  (kHz)  at  which  TL  +  NL  minima  occur  for  various  wind  speeds  in  m/s 
(rows)  and  sea  water  temperatures  in  degrees  Celsius  (columns). 
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In  the  case  of  no  wind,  the  frequency  at  which  TL  +  NL  has  a  minimum  value  is 
approximately  30  kHz.  In  the  presence  of  wind  speeds  of  5-15  m/s,  this  frequency  can  be 
found  just  above  40  kHz.  We  will  define  the  frequency  at  which  the  least  losses  occur  for 
a  given  range,  the  optimum  carrier  frequency.  In  order  to  ensure  reliable 
communications,  it  is  desirable  to  choose  this  frequency  as  the  carrier  frequency  or  center 
frequency  when  considering  bandwidth. 


Figure  9  TL  +  NL  in  dB  versus  frequency  in  kHz  for  various  wind  speeds  at  a  range 
between  source  and  receiver  of  500  m  and  sea  water  temperature  of  20°C,  S  =  35 
ppt,  pH  =  8.0  and  D  =  50  m.  The  optimum  carrier  frequency  (kHz)  is  found  at 

the  minimum  value  of  TL  +  NL  . 


4.  Source  Level 

Now  that  TL ,  NL  and  optimum  carrier  frequency  are  known,  the  SL  required  to 
produce  a  desired  SNRa  in  dB  can  be  determined.  Although  high  source  levels  (>180  dB) 
are  possible  and  common  in  underwater  acoustic  communications,  they  introduce 
reverberation  which  prolongs  the  impulse  response.  Reverberation  cause  symbols  to 
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overlap  at  the  receiver,  which  is  called  intersymbol  interference.  Avoiding  intersymbol 
interference  by  reducing  reverberation  can  be  achieved  by  decreasing  the  SL.  Other 
motivations  for  minimizing  SL  are  transmission  security  and  energy  budget.  It  is 
therefore  relevant  to  balance  the  choice  of  transmit  power  with  the  expected  TL  and  NL 
and  desired  SNRa. 


1(r  FTTTTTTTTT!TTTTTTTTTlinTTTTTTTTTTTTTTTTITmTTTTTTTl!TTITTTTTTITTTTTTITI 
10  fi!!iiiii!lHi!iii||!i||iiiiiiiiliiiiiiiiiliiiiiiiii|:|iiiiii|i|ifiiiiiiif] 

10  h!!!!!!!!l!!!!!!!!!l:!!!!!!!!!!h!!!!!!!!i!!!!!!|||fjff!!!i!!!!i!!!!!!!!n 
10  riiiiiHiiusHmmimnHmiimmiiHiHmiHimimmnimm!! 

:::::::::: d ::::::::: ::::::::: c :::: zz^lz i ::::::::: :c ::::::::: c :::::::: :: 

1 10  ililllHlil!IHHHl:lMllimffillMHlHl!HMllll:lllHHHlHlllllHf! 

10^  riiiiiimtiiimiMsmimiMimiiiiiiiiiiiiiiiiwimiiiiiiiimiMfi 

- 'J - J - J* - - J - r - 

10  rf|ii|||i||ii|i|i|iii:ii  in  ini  i|in|||  |i|  |!|i  Mi  i|||:i||i  i||  ||I|i||nii  in 

- , - , - r - i - 1 - r - 

- - -  - - 1 - , - - I - 1 - - 1 - - r-- - - - 

io*  I . ' . i . ' . i . ' . i . 

120  130  140  150  160  170  180  190 

SL  (dB  re  1  M-Parms) 

Figure  10  Time-average  acoustic  power  Pavg  in  W  versus  SL  in  dB  for  Pref  =  IpPa,  Rref= 

1  m  for  p  =  1026kg/m3  and  c  =  1499m/s. 


The  time-averaged  radiated  acoustic  power  in  watts  for  a  time-harmonic, 
omnidirectional,  point  source  related  to  this  SL  is  given  by 


4 7UR\  ■  Pzf  SL/ 

p  _  ref  ref  _  ,  q  7l0 

1  avg  ^ 

pc 


(2.18) 


where  Pref  =  1  pPa  is  the  root  mean  square  reference  pressure,  Rref  =1  mis  the  reference 

a 

range  from  the  source,  p  is  the  density  of  the  medium  in  kg/m  and  c  is  the  speed  of 
sound  in  m/s  in  that  medium  at  a  given  depth,  salinity  and  temperature  (see  Figure  10). 


16 


III.  PHYSICAL  LAYER 


The  Open  Systems  Interconnection  (OSI)  reference  model,  which  was  developed 
for  terrestrial  purposes  by  the  International  Organization  for  Standardization  (ISO) 
consists  of  seven  layers  of  standards  that  can  be  developed  independently  and 
simultaneously.  Data  moves  down  through  these  layers  before  being  transmitted  and 
moves  up  again  at  the  receiver.  Although  this  model  is  rarely  achieved  in  practice,  its 
structure  has  proven  useful  for  the  development  of  network  protocols.  We  will  use  this 
model  as  a  way  to  guide  us  through  the  process  of  studying  Seastar  networking  aspects 
by  focusing  only  on  the  lowest  three  layers:  the  physical  layer,  link  layer  and  network 
layer. 


Application 

Presentation 

Session 

Transport 

Network 
Data  link 
Physical 


Figure  1 1  OSI  model 


The  physical  layer  describes  the  transmission  of  digital  symbols  over  the  physical 
medium  and  deals  with  mechanical,  functional,  structural  and  procedural  characteristics 
to  access  the  medium.  The  challenge  within  the  physical  layer  is  to  use  the  very  limited 
bandwidth  that  is  available  in  the  underwater  channel  as  efficiently  as  possible. 
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A. 


MODULATION 


An  issue  that  needs  to  be  addressed  is  finding  a  suitable  waveform  modulation 
type.  Stojanovic  [18]  and  Akyildiz,  et  al  [19]  provide  useful  summaries  of  research  and 
developments  in  the  field  of  underwater  acoustic  communications.  Intersymbol 
interference  due  to  multi-path  arrivals  and  a  time-varying  channel  seriously  degrade 
communication  performance.  Since  mobile  nodes  are  not  excluded  from  being  part  of  a 
Seastar  network,  the  Doppler  effect  due  to  motion  of  transmitter  and/or  receiver  is 
another  factor  that  contributes  significantly  to  performance  degradation.  Frequency  shift 
keying  (FSK)  modulation  techniques  using  phase-incoherent  demodulation  techniques 
are  least  sensitive  to  these  channel  fluctuations  and  are  traditionally  used  for  underwater 
communications.  Recently,  coherent  demodulation  techniques  to  detect  phase  shift 
keying  (PSK)  modulation  and  quadrature  amplitude  modulation  (QAM)  have 
demonstrated  feasibility  for  use  under  water  [18,  19].  Various  forms  of  PSK  and  QAM 
using  coherent  demodulation  have  shown  a  bit  rate  increase  of  an  order  of  magnitude 
compared  to  modulation  types  that  depend  on  incoherent  detection  techniques  [18,  19]. 
The  experimental  conditions,  however,  were  mostly  either  very  short  range  (<100m)  in 
the  vertical  direction  or  very  deep  water  with  rather  complex,  often  non-real-time 
detection,  equalization  and  signal  processing  techniques  at  the  receiver  [18,  19].  Tests 
using  existing  commercial  modems  with  PSK  modulation  conducted  in  the  anechoic 
chamber  and  anechoic  water  tanks  at  NPS  demonstrated  a  very  poor  performance,  as  will 
be  discussed  in  Chapter  IV,  whereas  MFSK  modulation  was  generally  reliable.  Although 
the  developments  in  the  field  of  coherent  demodulation  look  promising,  it  is  so  far 
considered  not  yet  feasible  for  Seastar  purposes.  We  will  therefore  focus  on  modulation 
techniques  that  do  not  depend  on  coherent  detection  and  accept  the  bit-rate  limitations. 

1.  M-ary  Frequency  Shift  Keying  (MFSK) 

MFSK  has  proven  to  be  a  robust  modulation  scheme  for  underwater 
communications  under  various  conditions  [18,  19].  MFSK  [20-23]  uses  multiple  (M) 
frequencies,  offset  from  the  carrier  frequency,  to  represent  M  different  symbols,  each 
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containing  rib  bits  so  that  M  =2nb .  An  MFSK  signal  is  a  pulse  train  as  shown  in  Figure 
12  (e.g.,  see  [20])  and  is  represented  in  the  time-domain  by 


x(t)  =  Yjxn(t-tn),  0<t<Td 


where  the  /7th  pulse,  representing  one  of  the  M  symbols,  is  given  by 

f  t  —  0.5T^ 


(t )  =  A  cos  ( 2n[fc  +  A fn  ]t  +  en )  rect 


J 


where 


(3.1) 


(3.2) 


N\  total  number  of  pulses  (symbols)  transmitted  in  time  interval  0  <t  <Td 

tn\  time  instant  in  seconds  when  the  /7th  pulse  begins 

T,f.  total  duration  in  seconds  of  the  transmitted  signal  (pulse  train) 

fc :  carrier  frequency  in  hertz 

Afn\  frequency  offset  of  pulse  in  hertz  representing  a  unique  symbol 

en :  unintentional  additional  phase  shift  of  nth  pulse  in  radians 

T:  pulse  length  (symbol  duration)  in  seconds  of  an  individual  pulse  (symbol) 

in  the  pulse  train.  One  symbol  is  equal  to  rib  bits. 
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Figure  12  An  example  of  4-ary  frequency  shift  keying  (MFSK)  using  M  =  4 
frequencies  to  represent  M  =  4  different  symbols. 
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In  (3.2),  a  rectangle  function  is  used  to  shape  the  pulse,  but  other  windowing 
functions  are  not  excluded.  The  duration  of  a  symbol  T  is  given  by 

T  =  nbTb,  (3.3) 

where  Ti,  is  the  bit  duration  in  seconds.  The  total  signal  duration  Td  is  then  expressed  as 
NT  seconds.  The  additional  phase,  sn,  is  included  because  unintentional  phase  shifts  at  the 
transmitter  are  hard  to  avoid.  If  the  frequency  offset  is 

4 f,=j.  (3-4) 

where  k„  is  a  positive  or  negative  integer,  then  the  individual  pulses  are  orthogonal  even 
with  phase  shift  sn,  that  is  (e.g.  see  [21]), 

{xm  (0>*»  (0)  =  J  xm  (0-T  {t)dt  =  EXmSm  n,  m, n  =  1,2,...,M  ,  (3.5) 

where  SmM  is  the  Kronecker  delta  and  E  is  the  energy  contained  in  symbol  m  given  by 

E,m  ={xm{t)’xm{t))=  J  \xn,{t)\2  dt  =  ^A2T,  m  =  1,2,...,M  .  (3.6) 

The  factor  kn  is  an  integer  that  determines  the  spreading  of  the  frequencies.  One  possible 
set,  the  one  that  minimizes  bandwidth  and  allows  the  bandwidth  to  be  centered  around  an 
optimum  carrier  frequency,  is  k„e{±l,±2,...,±M/2]  and  is  used  for  this  analysis.  Other 
sets  such  as  k„e{±l,±3,...,±(M-l)},  which  spread  the  frequencies  more  sparsely,  are  also 
allowed. 


Now  that  we  know  the  representation  of  the  signal  in  the  time  domain  and  the 
conditions  for  orthogonality,  we  will  proceed  by  finding  an  analytical  expression  for  an 
MFSK  signal  that  relates  its  bandwidth  to  bit  rate  and  the  number  of  bits  per  symbol  nb . 


The  first  step  is  to  take  the  Fourier  transform  of  (3.1). This  gives 


+  Mf+fc)T 


Z  sinc  {[/  -  (fc  +  Afn )]  T]  e+jW"Te 


\,T  -jlKfixT 


AT  c+Mf-fc)r  y 


Z  sinc{[/  +  (/<■  +  Afn )]  T } 


-jlxfiiT 


The  frequency  spectrum  is  therefore  a  series  of  sine-functions  with  maxima  at 


f  =  fc+Afn  and  zero  crossings  that  overlap  each  other  exactly.  In  general,  sinc(  /T ) 
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equals  zero  at  f  =i/T  where  i  =  ±l,±2,.„,  and  exists  for  all  frequencies.  An  infinite 
bandwidth  is  not  realistic  and  therefore  a  judgment  call  is  required  for  defining 
bandwidth.  Note  that  bandwidth  is  always  measured  along  the  positive  frequency  axis.  A 
rule  of  thumb  for  unit- amplitude  sinc-functions  is  that  the  bandwidth  is  equal  to  a 
frequency  interval  where  |sinc(/T)|  >  0.1 .  As  Figure  13  shows,  sinc(  /T)|  <  0.1  for 
/  >  3/T ,  which  refers  to  the  location  of  the  third  zero  crossing  of  the  baseband  sinc- 
function.  Choosing  the  location  of  the  next  zero  crossing,  such  as  /  =  4/T ,  or  even 
f  =  5/T  ,  results  in  a  more  conservative  estimate  of  signal  bandwidth. 


Figure  13  Magnitude  spectrum  of  sin c(/T) . 


Although  it  is  often  common  to  determine  the  bandwidth  for  a  baseband  sinc-function 
using  /  =  l/T ,  it  is  really  an  underestimation.  In  this  thesis,  we  will  choose  a 
conservative  estimate  of  bandwidth  set  at  /  =  5/T  for  baseband,  unit-amplitude,  sinc- 
functions,  although  we  do  study  the  impact  of  other  values  later  in  this  section. 
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The  bandwidth  of  the  MFSK  frequency  spectrum  given  by  (3.7)  is  determined 
next.  An  estimate  of  the  maximum  positive  frequency  component  fmax  of  (3.7)  is 

/.=/,«  A/„+|.  (3-8) 

which,  upon  substitution  of  (3.4)  and  kn  =  M / 2  into  (3.8),  gives 


r  r  M  15 

/max  -  fc  +  f 

An  estimate  of  the  minimum  positive  frequency  component of  (3.7)  is 

/^=/,+minV,-|-  =  /t-Y^-|  (3.10) 

Therefore,  an  estimate  of  the  required  bandwidth  for  transmitting  an  MFSK  signal  is 

=  +  y  =  (3.11) 


Finally,  upon  introducing 


(3.12) 


where  D  is  defined  as  the  symbol  rate  or  baud  in  symbols  per  second,  the  bandwidth 
formula  given  by  (3.1 1)  can  be  rewritten  as 

BWX=(M  +10)  D.  (3.13) 

Substitution  of  (3.3)  into  (3.12)  gives 

D  =  —  (3.14) 

n„ 

where 


is  the  bit  rate  in  bits  per  second  (bits/s). 


(3.15) 


Equation  (3.13)  is  an  estimate  of  the  bandwidth  of  an  MFSK  signal  in  terms  of  the 
symbol  rate  D  and  the  number  of  unique  symbols  M.  The  definitions  for  bit  rate  and 
symbol  rate  or  baud  in  the  literature  are  sometimes  confusing  since  it  may  be  unclear 
whether  these  rates  refer  purely  to  information  bits  or  to  raw  bits  including  headers  and 
bits  for  coding  and  error  detection/correction,  generally  summarized  as  overhead.  The 
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definitions  for  D  and  R /,  as  stated  in  this  thesis  refer  to  symbols  and  raw  bits  including 
overhead,  meaning  that  the  actual  information  rate  may  very  well  be  lower. 

Before  any  conclusions  are  made  on  a  suitable  bandwidth  for  a  Seastar  network, 
(3.13)  will  be  analyzed  in  more  detail.  For  this  analysis,  M  =  2"b  represents  the  number 
of  different  symbols  that  can  be  created  based  on  the  number  of  bits  For  example,  if 
nb  =  2,  then  there  are  M  =  4  possible  symbols  consisting  of  two  bits:  00,  01,  10  and  11. 
This  requires  four  offset  frequencies.  Note  that  both  M  and  D  depend  on  rib,  the  number 
of  bits  per  symbol.  Therefore,  the  relation  between  bandwidth  BWX,  symbol  rate  D.  and  M 
can  also  be  expressed  in  terms  of  rib  and  the  bit  rate  Rb,  and  is  shown  in  Figure  14. 
Rewriting  (3.13)  in  terms  of  rib  gives 

BWX  =  ( 2"&  +10)  — .  (3.16) 

n. 


Figure  14  Bandwidth  BWX  in  kHz  of  a  MFSK  signal  versus  bit  rate  Rb  in  bits/s  for 
different  number  of  bits-per-symbol  (rib).  A  reduction  of  the  number  of 
frequencies  A fn  by  reducing  rib  does  not  always  result  in  a  smaller  BWX. 

At  first  glance,  Figure  14  shows  what  is  expected:  for  a  given  value  of  rib, 
increasing  the  bit  rate  comes  at  the  cost  of  increasing  bandwidth.  Examining  the  figure 
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more  carefully  reveals  an  interesting  phenomenon.  As  in  increases,  the  number  of 
frequency  offsets  Afn  increases  and  one  would  expect  an  increase  in  signal  bandwidth. 
This  expected  trend  apparently  breaks  down  for  a  fixed  value  of  Rb  and  for  small  ii/,  and 
shows  the  opposite  effect.  The  following  example  illustrates  this  numerically. 

For  Rb  =  1000  bits/s  and  nh  =  3  bits/symbol,  the  transmission  bandwidth  is 
BWX  =6  kHz.  For  nb=  5  bits/symbol,  BWX  =8.4  kHz  shows  the  expected  increase  in 
transmission  bandwidth  BWX.  If,  on  the  other  hand,  a  lower  number  of  bits  per  symbol  is 
chosen,  for  example  nb  =  2  bits/symbol,  we  find  B W,  =7  kHz,  which  is  larger  than  the 
bandwidth  for  nb  =  3  bits/symbol.  This  implies  the  existence  of  an  optimum  value  for  nh 
for  a  given  value  of  Rb . 


Figure  15  Bandwidth  BWX  in  kHz  of  a  MFSK  signal  versus  in,  the  number  of  bits  per 
symbol  for  different  bit  rates  Rb  in  bits/s.  If  a  minimum  transmission  bandwidth  is 
desirable,  an  optimum  value  for  nb  can  be  found  near  nh  =  3 . 
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The  optimum  value  for  rib  becomes  obvious  when  plotting  bandwidth  BWX  versus 
nb  for  a  given  Rb  (see  Figure  15).  If  (3.16)  is  rewritten  as  follows 


BWx=(Tb  +2z)^. 


(3.17) 


where  z  defines  the  number  of  zero  crossings  of  the  sine-function  (previously  z  =  5  ),  then 
in  order  to  find  the  optimum  value  of  nb  that  will  minimize  BWX  for  a  given  value  of  Rb 
and  z,  we  need  to  solve  the  following  equation: 


d  R  2"b 

BW=^L 


d  n. 


1 


In  2 - 


2  z 


nb  nb2'h  j 


=  0 


or 


77,  ln2  =  l  +  — . 

Tb 


(3.18) 


(3.19) 


Figure  16  Graphical  solution  of  the  transcendental  equation  given  by  (3.19).  A  more 
conservative  definition  of  bandwidth  shifts  the  optimum  value  for  nb  from  2 

(z  =  l)to3(z  =  3  and z  =  5 ). 


Equation  (3.19)  is  a  transcendental  equation  which  is  independent  of  Rb.  Figure  16 
is  a  graphical  solution  of  (3.19)  and  shows  that  the  optimum  value  of  nb  depends  on  the 
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choice  for  z  and,  therefore,  on  the  definition  of  bandwidth.  Rounding  the  values  to  the 
nearest  integer  shows  that  the  optimum  values  for  nb  are:  nh  =  2  for  z  =  1 ,  and  nh=  3  for 
z  =  3  and  z=5 .  The  existence  of  an  optimum  number  of  bits  per  symbol  can  be 
explained  by  the  relatively  small  impact  that  the  term  2"b  in  (3.16)  has  at  low  values  of 
nb  compared  to  the  1 Jnb  factor.  The  term  2""  quickly  starts  to  dominate  at  values  of  nh 
greater  than  three. 

The  general  impact  of  z  on  BWX  is  shown  in  Figure  17.  The  definition  of 
bandwidth,  again,  is  subjective  and  allows  for  both  over-  and  underestimation  of 
achievable  bit  rates.  The  conservative  choice  of  z  =  5  results  in  a  BWX  that  is  almost 
twice  as  large  as  a  bandwidth  definition  based  on  the  first  zero  crossing  ( z  =  1  )• 


Figure  17  Influence  of  the  choice  for  the  number  of  zero  crossings  z  on  bandwidth  BW, 
for  nb=  3 .  The  relation  between  BWX  in  kHz,  Rb  in  bits/s  and  z  is  given  by  (3. 17). 


We  summarize  this  section  by  stating  that  a  parametric  analysis  can  be  performed 
on  MFSK  signals.  The  analysis  of  (3.16)  has  revealed  some  interesting  and  useful 

relations  between  bandwidth  BWX,  bit  rate  Rb,  the  number  of  symbols  M.  the  number  of 
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bits-per-symbol  nh  and  the  definition  of  bandwidth  based  on  (3.7).  One  should  be  careful 
and  precise  in  defining  the  bandwidth  for  a  sinc-function.  This  choice  has  a  profound 
effect  on  the  maximum  transmission  bandwidth  and  may  even  result  in  adjusting  nh 
when  minimizing  bandwidth.  Equation  (3.19)  and  Figure  16  show  that  for  a  bandwidth 
defined  below  the  third  zero  crossing  ( z  =  1  or  2 ),  the  optimum  value  for  nh  is  nh  =  2 . 
For  a  bandwidth  defined  by  z  =  3,4  or  5 ,  the  optimum  value  for  nh  is  nb  =  3 .  Although 
this  optimization  for  nh  is  useful  for  minimizing  transmission  bandwidth,  Figure  14 
shows  that  higher  bit  rates  require  larger  bandwidths  for  given  a  value  for  nh . 


2.  Orthogonal  Frequency  Division  Multiplexing  (OFDM) 


The  OFDM  technique  has  been  claimed  to  be  one  of  the  most  promising  future 
communications  technologies  for  achieving  high  data  rate  and  large  system  capacity  [24] 
and  is  expected  to  be  a  valid  and  robust  communications  technique  for  underwater  use 
[19].  Although  the  performance  has  only  been  tested  marginally  in  an  experimental  setup 
[25],  simulations  [25,  26]  indicate  that  the  technique  allows  avoidance  of  intersymbol 
interference. 


OFDM  uses  a  multi-carrier  modulation  scheme  to  transmit  broadband  data  in 
parallel  over  N  orthogonal  carriers  which  allows  spectral  efficiency  and  eliminates  the 
use  of  guard  bands  between  the  carriers  [24].  In  this  section,  we  will  derive  a  formula  for 
OFDM  that  allows  us  to  analyze  the  relation  between  bandwidth  versus  bit  rate  and  other 
characteristics.  This  will  then  be  compared  to  the  MFSK  analysis  that  was  done  in  the 
previous  section. 


The  time  domain  equation  for  OFDM  is  given  by  Couch  [27]  as  (see  Figure  18) 

*(0  =  Z-T,(0,  o  <t<Td,  (3.20) 

n= 0 

where 


it)  =  A\w«\ cos  (l7r[fc  +  Afn  ] t  +  +  £n ) rect 

+  /Zw„ 

y  J  n 


rt-0.5Td^ 


ld  ) 


(3.21) 


,  =  \Wn\e 
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w, 


V 


(3.22) 


(3.23) 


and  where 


A/„  =  — ,  n  =  0,  -l. 


rect 


f  t-0.5Td^ 

J 

{  Td  J 

“1 

|1,  0  <t<Td, 

1 0,  otherwise, 


(3.24) 


N:  total  number  of  pulses  (symbols)  transmitted  in  time  interval  0  <t  <Td 

wn :  complex-valued  input  symbol 

Td'.  total  duration  in  seconds  of  the  transmitted  OFDM  signal 
fc :  carrier  frequency  in  hertz 

A fn:  frequency  offset  in  hertz 

en\  possible,  unwanted  phase  shift  in  radians. 


Td 


Figure  18  An  example  of  OFDM  with  N  =  3  sub-carriers  transmitting  for  Td  seconds. 
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The  relation  between  the  total  duration  Td  of  N  simultaneous  transmitted  pulses,  the 
duration  of  an  input  symbol  T  in  seconds  and  the  bit  duration  Tb  in  seconds  is 

T,  =  NT  (3.25) 

where 

T  =  nbTh  (3.26) 

and  where  nh  is  the  number  of  bits  per  symbol.  The  offset  frequencies  do  not  refer  to 
unique  symbols  as  with  MFSK.  Instead,  symbol  modulation  is  achieved  by  varying  the 
amplitude  ( |  wn  | )  and/or  the  phase  ( Zwn )  of  a  sub-carrier. 

Taking  the  Fourier  transform  of  (3.20)  results  in  the  following  expression  for  the 
complex  frequency  spectrum  of  an  OFDM  transmitted  signal: 

^(/)  =  ^«"M/"4’r'lil%|stac{[/-(/r+A/,)]Tqe*»r'««z'-  + 

n  (3-2?) 

^  n= 0 

where 

Zc„=Zw„+£„.  (3.28) 

As  with  MFSK,  this  frequency  spectrum  is  a  series  of  sine-functions  with  maxima  at 
f  =  fc+  A fn  and  zero  crossings  that  overlap  each  other  exactly.  Recall  that 

sinc(/T/)  =  0  at  f  =  i/Td  where  i  =  ±l,±2,.„ ,  and  that  |sinc(/Td)|  <  0.1  for  f>3/Td 
(see  Figure  13)  which  refers  to  the  location  of  the  third  zero  crossing  of  the  baseband 
sine-function.  In  contrast  to  MFSK,  fc  is  not  the  center  frequency  -  it  is  the  lowest 

frequency  (n  =  0) ,  thus  making  the  maximum  frequency  offset 

N- 1 

max  Afn  =  ——  (3.29) 

‘  d 

and  the  minimum  frequency  offset 

min  Afn  =  0 .  (3.30) 
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The  bandwidth  is  defined  as 


BW  =  f  -f.= 

x  J  max  J  min 


fc  +  max  Afn+  — 


ldj 


f  +  min  Af  -  — 

J  c  J  n  m 


(3.31) 


ld  J 


where  z  is  the  integer  number  of  zero  crossings  of  the  sinc-function  that  are  used  to 
estimate  both  the  maximum  and  minimum  frequency  components.  Substitution  of  (3.29) 
and  (3.30)  into  (3.31)  gives 

iV  +  2z-l 


BW 


which,  upon  substituting  (3.25),  can  be  rewritten  as 


(3.32) 


BW, 


(  2  z-O 

1  +  — — 

l  N 


The  input  symbol  rate,  or  baud,  is  (see  [27]) 


D.  =  — 


1  1 


R, 


T  nbTb 


(3.33) 


(3.34) 


where  Rb  is  the  bit  rate  in  bits/s.  Finally,  when  (3.34)  is  substituted  into  (3.33),  the 

following  analytical  expression  for  an  OFDM  transmitted  signal  relating  its  bandwidth  to 
bit  rate  is  found: 


f 


BW,  = 


2z-l 


1+- 

v  N  )nb 


R 


(3.35) 


The  next  step  is  to  make  a  fair  comparison  with  MFSK.  One  way  to  do  this  is  to 
demand  the  same  number  of  symbols  N  to  be  transmitted  over  a  certain  time  period  Td 
for  both  transmission  schemes  and  compare BWX.  It  can  be  seen  from  (3.1)  and  (3.20) 
that  MFSK  transmits  N  symbols  in  series  in  the  time  interval  Td  as  short  pulses,  each 
with  duration  T ,  whereas  OFDM  transmits  the  same  number  of  symbols  in  parallel  with 
duration  Td .  Having  thus  ensured  that  a  fair  comparison  is  possible,  we  start  the  OFDM 

parametric  analysis  by  setting  N  as  the  variable  and  observing  the  relation  with  BW,  . 


This  is  done  simultaneously  for  z  =  1, 3  and  5  ,  nh  =  3 ,  and  Rh  =  2000  bits/s  as  shown  in 
Figure  19.  Two  important  trends  can  be  observed  from  Figure  19. 
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First,  it  shows  that  increasing  the  number  of  sub-carriers  reduces  the  bandwidth. 
In  other  words,  transmitting  long  symbol  sequences  (large  N)  in  parallel  is  favorable  in 
terms  of  bandwidth  reduction.  Note  from  (3.1)  and  (3.25)  that  this  increases  the  total 
transmission  duration  Td  for  both  modulation  schemes  in  the  same  amount. 


Figure  19  Bandwidth  BWX  in  kHz  versus  number  of  OFDM  sub-carriers  N  for 

Rb  =  2000  bits/s,  nb=  3 ,  and  z  =  1,  3  and  5  . 


The  second  trend  that  is  observed  from  Figure  19  is  that  the  bandwidth  for  any  z 
reduces  asymptotically  to  the  same  value,  which  for  Rb  =  2000  bits/s  and  nb  =  3  is 

BWX  ~  667  Hz.  Recall  that  z  =  1  is  most  commonly  used,  z  =  3  represents  the  case  where 
|sinc(/Trf)|  <  0.1,  and  z  =  5  is  the  conservative  case.  This  asymptotic  behavior  is  also 
described  by  Couch  [27]  and  by  using  (3.35)  and  (3.34)  translates  in  our  case  as  follows: 


For  z  =  1: 


f 


BW,  = 


1 


1  +  — 

v  Nj 


D.  and  if  TV  >  10,  then  BWX  »  D. 


(3.36) 
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For  z  =  3 : 


BWr  = 


For  z  =  5: 


BWr  = 


Ml 

l  NJ 


.  Nj 


D.  and  if  N  >  50,  then  BWX  «  D. 


D  and  if  N  >  90,  then  BWX  ~  D 


(3.37) 


(3.38) 


As  a  rule  of  thumb,  it  can  thus  be  stated  that  if  N  »  (2 z  - 1) ,  BWX~  Din . 


Keeping  nh  =  3  and  letting  A  =  100,  the  relation  between  BWX  and  Rb  for 
z  =  1,  3  and  5  given  by  (3.35)  is  shown  in  Figure  20.  Figure  20  shows  that  much  higher 
bit  rates  can  be  obtained  by  using  OFDM  compared  with  MFSK  (see  Figure  17)  for 
similar  values  of  BWX .  It  also  confirms  that  BWX  ~  Din  for  large  N  and  it  shows  that  the 

choice  for  z  does  not  have  a  similar  impact  on  required  BWX  as  is  the  case  with  MFSK. 


Figure  20  Bandwidth  BWX  in  kHz  versus  bit  rate  Rb  in  bits/s  for  OFDM  with  nh  =  3 , 

N  =  100 ,  and  z  =  1, 3  and  5  . 
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It  may  already  be  obvious  from  (3.35)  that  a  large  number  of  bits  per  symbol  ( nb ) 


reduces  the  bandwidth  as  is  illustrated  by  Figure  21. 


Figure  21  Bandwidth  BWX  in  kHz  versus  number  of  bits  per  symbol  nh  for  N  =  100, 

z  =  5  and  Rb  =  2000  bits/s. 


Finally,  Figure  22  compares  OFDM  to  MFSK  for  z  =  1,  3  and  5,  N  =  100,  and 
nb=  3 .  It  can  be  seen  that  for  a  given  Rb ,  the  required  OFDM  bandwidth  BWX  is  always 
less  than  the  required  MFSK  bandwidth  and  that  the  achievable  OFDM  bit  rate  is  much 
higher  than  the  MFSK  bit  rate  (see  Figure  17)  for  a  given  BWX . 

In  summary,  under  similar  conditions,  OFDM  requires  significantly  less 
bandwidth  than  MFSK  to  achieve  a  certain  bit  rate  Rb .  The  biggest  advantage  of  OFDM 

is  that  a  high  Rb  for  a  given  BWX ,  or  a  small  BWX  for  a  given  Rh  can  easily  be  achieved 

by  increasing  the  number  of  sub-carriers  N.  Although  OFDM  may  seem  the  best 
modulation  technique  to  use  for  Seastar,  it  must  be  emphasized  that,  to  our  knowledge, 
no  in-water  experiments  have  been  conducted  yet  that  confirm  this  behavior  and  that 
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demonstrate  similar  robustness  in  the  underwater  channel  as  MFSK.  The  developments  of 
OFDM  for  underwater  purposes  need  to  be  followed  closely  since  OFDM  has  the 
potential  to  be  a  future  candidate  for  Seastar  applications. 


Figure  22  Bandwidth  BWV  in  Hz  versus  bit  rate  Rh  in  bits/s  with  z  =  1,  3  and  5 , 
N  =  100,  and  nh  =  3  for  OFDM  and  MFSK.  To  achieve  a  certain  Rh ,  OFDM 
requires  significantly  less  bandwidth  than  MFSK. 


B.  PRACTICAL  CONSIDERATIONS 

Seastar  involves  half-duplex  communications,  meaning  that  the  individual  nodes 
are  not  able  to  receive  and  transmit  at  the  same  time.  Communication  ranges  within  a 
Seastar  network  are  confined  to  500  m,  by  design.  Mobile  nodes  like  unmanned  undersea 
vehicles  (UUVs)  or  divers  are  not  excluded  from  being  part  of  such  a  network.  Seastar 
anticipates  an  almost  continuous  information  flow  from  an  arbitrary  number  of  peripheral 
nodes.  A  centralized  configuration  with  a  deterministic  form  of  transmission  control  and 
a  central,  sophisticated,  Seaweb  access  point,  capable  of  fusing  data  and  accepting  data 
transmissions  from  cheap  and  unsophisticated  nodes  to  reduce  cost,  introduces 
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asymmetry.  Transmit  and/or  receive  arrays  containing  multiple  transducers  are  useful  for 
steering  or  focusing  a  signal  to  avoid  unwanted  multiple  arrivals  and  would  provide  array 
gain.  Cost  constraints,  however,  make  the  use  of  arrays — including  the  required  signal 
processors  at  the  peripheral  nodes — highly  unlikely.  However,  receive  and/or  transmit 
arrays  at  the  sophisticated  central  node  are  not  excluded. 

1.  Peer-to-Peer  Communications 


The  centralized  setup  requires  two-way  communication  between  the  central  node 
and  peripheral  nodes.  Depending  on  the  preferred  topology  and  potential  need  for  node- 
to-node  ranging  and  localization,  communication  amongst  peripheral  nodes  may  be  an 
additional  requirement.  This  imposes  a  further  restriction  on  the  geometry.  Consider  the 
case  of  a  uniform  radial  distribution  of  peripheral  nodes,  as  illustrated  by  Figure  23,  for 
the  special  case  of  five  nodes,  where  the  central-to-peripheral  node  range  in  meters  is 
given  by 

R  =  yjh2  +(r/2)2  ,  (3.39) 

where  r  is  the  peripheral  node-to-node  range  in  meters.  In  this  geometry, 

h  =  Rcos(0/  2)  (3.40) 

where  6  is  the  angle  that  symmetrically  distributes  peripheral  nodes  around  the  central 
node  as  follows 


n 


(3.41) 


with  n  being  the  number  of  nodes.  At  least  six  symmetrically  spaced  nodes  are  required 
to  ensure  communications  at  the  maximum  range  between  both  central  and  peripheral  as 
well  as  neighboring  peripheral  nodes.  Calculating  the  range  excess  R'.  given  by 

r-R 


R' 


R 


-x  100%  =  [2R  sin(;r  /  n)  - 1]  x  100% 


(3.42) 


that  is  required  in  case  of  fewer  nodes  or  the  reduced  range  Rrect  to  maintain  neighboring 
node  communications  is  trivial  and  results  in  Table  2.  Using  fewer  nodes  imposes  no 
restriction  when  only  central-peripheral  communications  are  considered. 
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Figure  23  Network  geometry  with  five  symmetrically  distributed  nodes.  At  least  six 

nodes  are  required  to  ensure  r  <R  . 


n 

R' 

reduced  Rred  (r=500m) 

2 

100% 

250m 

3 

73% 

289m 

4 

41% 

354m 

5 

18% 

425m 

Table  2  Required  range  excess  and  reduced  range  in  case  of  less  than  6  nodes. 


2.  Transmit  Transducer 

The  next  issue  involves  the  practical  realization  of  the  transmission  of  a 
modulated  waveform,  mathematically  represented  by  (3.1).  A  factor  that  severely  limits 
the  useful  band  is  the  transmitting  sensitivity  level  or  transmit  voltage  response  ( TVR )  of 
a  transducer.  The  TVR  is  defined  as  the  ratio  of  the  pressure  response  of  a  transducer  to 
the  applied  voltage  and  is  commonly  expressed  in  units  of  dB  re  1  pPa/V  @  1  m  [7,  31]. 
In  general  the  TVR  of  a  transducer  over  its  operating  band  is  not  constant.  The  usable 
bandwidth  of  a  transducer  is  commonly  described  by  the  mechanical  quality  factor, 
which  is  defined  as 
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•  =-L_ 

fu-f, 


(3.43) 


where  fc  is  the  center  frequency,  or  resonance  frequency,  and  f„  and  f\  are  the  upper  and 
lower  frequencies,  respectively,  at  which  the  average  power  has  dropped  to  one-half  its 
value  at  the  resonance  frequency  [7,  28].  A  high  Qm  represents  a  frequency  response 
spectrum  with  a  sharp  peak,  whereas  a  low  Qm  represents  a  broader  frequency  response. 
The  TVR  will  act  as  an  additional  filter  on  the  transmitted  waveform.  As  an  example,  a 
quick  survey  of  commercially  available  transducers  [29,  30]  shows  that  a  low  Qm  of  2  to 
3  is  not  unreasonable  near  the  frequency  band  of  interest. 

Another  limiting  factor  imposed  by  the  transducer  is  the  rise  time  for  a  pulse  to 
reach  steady  state.  Recall  that  (3.2)  uses  a  rectangle  function  to  describe  a  pulse.  The  rise 
time  will  affect  the  frequency  spectrum  that  is  transmitted,  which  has  an  impact  on 
bandwidth  and  achievable  data  rates.  It  may  also  affect  the  orthogonality  of  the  individual 
pulses  depending  on  the  modulation  type.  The  rise  time  in  seconds  to  reach  96%  of  the 
steady-state  amplitude  is  give  by  [31] 

t .  =~sl.  (3.44) 

rise  r  v ' 

J  c 

Another  way  of  describing  this  is  that  Qm  cycles  are  required  for  the  amplitude  to  build 
up  to  96%  of  its  final  value,  or  reduce  to  4%  of  its  maximum  value.  Short  pulses  will  be 
affected  relatively  more  than  long  pulses. 

3.  Multi  -access  Interference 

Although  an  individual  LAN  manages  its  own  internal  channel  access,  it  needs  to 
be  considered  that  Seastar  networks  might  operate  in  each  other’s  vicinity.  Interference 
has  a  dramatic  impact  on  the  performance,  as  will  be  shown  in  Chapter  V,  and  frequency 
separation,  resulting  in  bandwidth  reduction,  may  be  the  only  physical  solution  to 
overcome  this  problem. 
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C.  PHYSICAL  LAYER  CASE  STUDY 

Let  us,  as  an  example,  analyze  the  physical  layer  by  performing  a  case  study  to 
identify  a  reasonable  transmission  bandwidth,  capacity  and  energy  budget.  Doing  so 
requires  approximations  and  assumptions  on  several  factors  such  as  transducer 
performance  and  channel  properties. 

For  wind  conditions  of  5-15  m/s  shown  in  Table  1,  the  optimum  carrier  frequency 
can  be  found  to  be  approximately  41  kHz.  For  convenience,  we  choose /c=40  kHz.  The 
practical  bandwidth  is  governed  by  TL  +  NL  versus  frequency  spectrum  and  transducer 
properties.  An  additional  consideration  is  that  the  frequency  band  should  be  separated 
from  the  Seaweb  band  (currently  9-14  kHz).  Assuming  that  a  Q„ ,  of  2  is  achievable,  the 
half-power  bandwidth  based  on  (3.43)  could  stretch  from  30-50  kHz  which  makes 
BWX  =  20  kHz.  For  a  transducer  with  a  Qm  of  2  and  fc  =  40  kHz,  applying  (3.44)  results 
in  a  rise  time  of  50  ps.  If  MFSK  is  the  preferred  modulation  type,  (3.13)  can  be  applied  to 
determine  maximum  achievable  bit  rate.  If  nn  =  3  bits/symbol,  then  M  =  23  =  8  ,  and  the 
modulation  type  becomes  8-FSK.  Based  on  (3.13)  and  (3.14),  the  maximum  achievable 
symbol  rate  D  is  then  approximately  1100  symbols/s  which  makes  Rb~  3300  bits/s. 

Recall  that  overhead  is  included  so  the  information  rate  will  be  lower  by  a  factor  that 
depends  on  the  type  of  error  detection  and  correction  coding  applied,  message  header 
lengths,  etc.  Using  (3.12),  the  pulse  length  T  for  a  symbol  would  have  a  minimum  length 
of  0.9  milliseconds  (ms)  meaning  that  the  ratio  of  trise  over  T  would  be  6%.  If  OFDM 
would  be  available,  bit  rates  of  Rb  ~  55000  bits/s  are  theoretically  possible  for  the  same 

BWX  =  20  kHz.  Further  analysis  would  be  required  to  determine  to  what  extent  the  signal 

would  be  affected  by  the  rise  time.  It  must  be  emphasized  that  the  frequency  spectrum  of 
the  transmitted  signal  given  by  (3.7)  has  been  convolved  by  both  the  channel  impulse 
response  and  the  TVR. 

The  final  step  in  our  case  study  is  to  determine  an  energy  budget  for  acoustic 
transmissions  to  a  range  of  500  m.  To  obtain  a  numerical  value  requires  additional 
approximations  and  assumptions.  Firstly,  our  analysis  is  limited  to  a  single-frequency 
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time-harmonic  signal  only,  and  A/  =  l  Hz  in  (2.15).  We  also  assume  a  specific  SNRa 
required  at  the  receiver  to  reliably  detect  an  incoming  signal.  Based  on  experience  with 
commercially  available  Teledyne  Benthos  ATM-885  acoustic  modems,  a  SNRa  of 
approximately  7  dB  at  the  receiver  input  ensures  a  probability  of  detection  of  more  than 
95%.  For  a  wind  speed  of  15  m/s  and  medium  shipping  density,  a  TL+NL  of  105  dB  at 
fc  =40  kHz  can  be  extracted  from  Figure  9.  However,  the  worst  case  TL  +  NL  for  a 

single-frequency  time-harmonic  signal  under  these  conditions  within  the  30-50  kHz  band 
is  106  dB  at  30  kHz.  Adding  the  7  dB  SNRa  to  the  maximum  TL  +  NL  value  results  in  a 
required  SL  of  113  dB  re  1  pPa  @  1  m  [see  (2.12)].  In  order  to  find  the  input  electrical 
power  to  achieve  this  SL,  we  need  transducer  TVR  and  impedance  data,  since  the  root- 
mean-square  input  electrical  power,  Prms,  in  watts  (W)  [32]  is  expressed  as 

+„=LR  =  ^R.  (3-45) 

where  irms  and  Vnm  are  the  root-mean-square  input  current  in  amperes  and  voltage  in 
volts,  respectively.  The  variable  R  is  the  transducer  resistance  and  IZI  is  the  magnitude  of 
the  transducer  impedance  in  ohms.  Although  Z  can  be  expressed  in  terms  of  resistance  R 
and  reactance  X,  it  is  more  common  to  express  the  characteristics  of  a  transducer  in  terms 
of  admittance  Y  where 

\Y\  =  —  =  Vg2+£2  ,  (3.46) 

1  1  IZI 

with  G  and  B  being  the  conductance  and  susceptance,  respectively.  The  units  for  Y,  G  and 
B  are  siemens  (S).  Equation  (3.45)  can  now  be  rewritten  as 

P  =V2  G.  (3.47) 

A  limited  survey  of  available  transducers  [29,  30]  yields  a  TVR  and  G  at  the  resonance 
frequency  of  145  dB  and  6500  pS,  respectively,  as  reasonable  values.  The  input  root- 
mean-square  power,  required  to  produce  a  SL  of  113  dB  re  IpPa  @  lm  can  be  found 
from 

101og(P„J  =  2Olog0/jJ  +  lOlog(G)  =  SL-TVR  +  lO\og{G) .  (3.48) 
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Inserting  the  values  for  SL,  TVR  and  G  in  (3.48)  results  in  an  input  electric  Prms  of  4.1  pW 
at  40  kHz  provided  that  this  is  also  the  resonance  frequency  of  the  transducer  to  generate 
a  SL  of  113  dB.  The  energy  required  to  transmit  one  symbol  of  duration  T  =0.9  ms, 
represented  by  a  single  frequency,  is  therefore  (4. 1  pW)  •  (0.9  ms)  =  3.7x  10 9  J  . 

Calculating  the  energy  to  receive  a  message  is  less  trivial  as  it  depends  on  the 
demodulator  and  amplifier  used  to  detect  and  decode  the  signal.  To  keep  our  analysis 
general,  we  use  a  method  for  calculating  energy  consumption  described  in  [33].  Although 
the  energy  efficiency  of  signal  processors  has  increased  over  the  years,  it  is  likely  that 
receiving  signals  at  higher  bit  rates  requires  more  energy.  We  therefore  do  not  make 
assumptions  on  improvements  of  receiving  power  and  take  a  typical  value  of  0.5  W  based 
on  [33]  for  the  power  required  to  receive  data.  In  summary,  to  ensure  transmission  of  a 
single  frequency  signal  at  40  kHz  over  a  range  of  500  m  at  wind  speeds  of  15  m/s  and 
medium  shipping  density  with  a  commercially  available  transducer,  requires  an  input 
electric  root-mean-square  power  of  4. 1  pW,  further  referred  to  as  P transmit-  Reception  of 
this  signal  under  the  same  conditions  requires  0.5  W,  further  referred  to  as  P receive- 

The  energy  budget  now  fully  depends  on  operational  settings  such  as  the  type  of 
network,  the  expected  number  of  transmissions,  bit  rates,  packet  size  and  the  number  of 
modems  that  are  part  of  this  network.  Nevertheless,  it  is  useful  to  continue  the  analysis  to 
ascertain  the  order  of  magnitude  of  the  required  energy  budget.  To  finalize  this  analysis 
we  consider  a  network  consisting  of  one  central  modem  receiving  data  packets  from,  and 
transmitting  control  packets  to,  six  peripheral  modems  over  fixed  ranges  of  500  m.  The 
preferred  modulation  type  is  8-FSK,  each  symbol  consisting  of  3  bits,  and  the  available 
bandwidth  is  20  kHz.  Each  peripheral  modem  is  assumed  to  transmit  one  data  packet  of  a 
fixed  length  of  2000  bytes  with  8  bits  per  byte  at  3300  bits/s  once  every  cycle  and  the 
central  modems  transmit  one  10-byte  control  packet  at  500  bits/s  to  each  peripheral 
modem  each  cycle.  For  each  byte  transmitted,  an  additional  redundant  byte  is  added  and 
additional  overhead  created  by  headers,  etc.,  is  ignored.  Each  transmission  is  successful 
and  no  dead  times  between  transmissions  are  considered.  One  transmission  from  a  central 
modem  to  a  peripheral  modem  therefore  requires  a  period  of 


40 


O  U, j-p  1  Q 

T  ,..=2x10  bytes  x- - x - =  0.32  seconds. 

C0nt'0'  byte  500  bits 

One  transmission  from  a  peripheral  modem  to  the  central  modem  requires  a  period  of 

O  Jaj |-q  1  ^ 

T.= 2x2000  bytes x - x - =  9.70  seconds  . 

da,a  byte  3300  bits 

The  total  required  energy  during  one  cycle  for  a  peripheral  modem  is  now 

r  _  T  <  D  I  T  <  p 

^ total ,  peripheral  ±  control  1  receive  L  data  1  transmit 

Etotal,peripheml  =  0.32s  ■  0.5  W  +  9.70s  ■  4.  lpW  =  0. 16J. 

The  total  required  energy  during  one  cycle  for  the  central  modem  is  now 

M 

E  —  T  .  p  -\~t  .  p 

^ total , central  data,m  1  receive  ±  control, m  1  transmit 

m=0 

=  6  •  (9.70s  ■  0.5W  +0.3  Is .  4.  ljiW)  =  29J, 

The  difference  between  required  energy  at  the  central  modem  and  the  energy 
required  at  any  of  the  peripheral  nodes  is  approximately  two  orders  of  magnitude. 
Although  these  values  originate  from  many  assumptions,  the  difference  is  significant 
enough  to  be  taken  into  account.  This  difference,  which  is  mainly  due  to  the  fact  that 
receiving  and  processing  a  signal  requires  more  power  than  transmitting,  will  further 
increase  with  a  larger  number  of  peripheral  modems  in  the  network.  Added  to  this  comes 
the  fact  that  the  central  modem  is  also  responsible  for  data  fusion  and  transmission 
through  a  Seaweb  network  which  makes  the  energy  budget  between  central  and 
peripheral  modems  even  more  asymmetric.  From  a  peripheral  modem’s  perspective,  we 
have  ignored  the  energy  required  by  other  components  of  the  peripheral  nodes,  such  as 
the  sensor  that  provides  data  for  transmission.  Data  transfer  from  sensor  to  modem  and 
modulating  this  data  requires  additional  energy  that  needs  to  be  included  in  the  peripheral 
modem’s  final  energy  budget. 

An  assumed  battery  capacity  at  the  central  modem  of  300  watt-hours  or  1.08 
megajoules  (MJ)  that  is  fully  available  for  the  Seastar  network  would  allow  Seastar 
network  operations  for  almost  26  days.  This  period  would  require  a  peripheral  node 
battery  capacity  of  6000  joules  (J)  or  1.7  watt-hours  permitting  a  smaller  size  and  cost  of 
these  nodes. 
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The  discussion  regarding  the  physical  layer  of  a  Seastar  network  is  summarized  as 
follows.  Seastar  is  able  to  operate  at  500  m  using  a  higher  frequency  spectrum  than 
Seaweb  for  a  period  of  about  one  month.  The  optimum  carrier  frequency  is  40  kHz  and, 
depending  on  the  modulation  type  and  signal  processing  techniques,  bit  rates  of  3000  bits 
per  second  should  be  achievable  using  MFSK  modulation  and  a  spectral  bandwidth  of  20 
kHz.  The  availability  of  OFDM  could  improve  the  performance  by  an  order  of 
magnitude.  The  energy  budget  for  central  and  peripheral  modems  is  asymmetric  and 
consistent  with  the  envisioned  topologies.  More  accurate  performance  data  requires  a 
further  study  of  the  effects  of  the  transducer  and  the  communication  channel  on  the 
waveform,  and  an  update  of  energy  consumption  considering  modems  optimized  for 
operation  at  the  frequency  band  of  interest. 
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IV.  DATA  LINK  AND  NETWORK  LAYER 


This  chapter  provides  a  framework  for  the  organization  of  the  dataflow  within  a 
Seastar  network.  The  set  of  rules  for  data  exchange  is  called  a  protocol  and  consists  in 
our  case  of  a  layered  structure  as  described  in  Figure  11.  Extensive  research  in  the  field 
of  access  control  during  the  last  decade  [19,  22,  23,  35-37]  provides  useful  advice  for 
designing  Seastar.  Network  issues  regarding  error  detection  and  correction  that  originate 
from  terrestrial  networks  are  considered  for  their  applicability  to  Seastar.  Finally, 
tradeoffs  regarding  topology,  the  physical  arrangement  of  stations,  are  presented. 
Combining  this  information  yields  the  design  of  a  prototype  Seastar  network  that  is 
discussed  in  the  last  section. 

A.  DATA  LINK  LAYER 

The  link  layer  is  responsible  for  ensuring  transmission  across  the  physical  layer 
between  two  neighboring  nodes  and  deals  with  synchronization,  error  control  and  flow 
control. 


1.  Access  Control 

Seastar  is  designed  for  multiple  users  to  transmit  information  to  a  central  node. 
In  this  multiple-access  environment,  it  is  necessary  to  share  the  transmission  medium  in  a 
manner  ensuring  that  packets  are  transmitted  without  interference  from  other  network 
users.  Research  for  applicability  of  terrestrial  multiple  access  control  techniques  for 
underwater  communication  purposes  [19,  22,  23,  35-37]  provides  useful  tradeoffs.  A 
distinction  can  be  made  in  deterministic  and  random  access  methods. 

Available  deterministic  access  methods  are  frequency-division  multiple  access 
(FDMA),  time-division  multiple  access  (TDMA)  and  code-division  multiple  access 
(CDMA).  FDMA  [23]  simply  divides  the  available  bandwidth  into  N  sub-channels, 
where  N  depends  on  the  number  of  nodes  in  the  network.  Since  we  anticipate  a  large 
number  of  nodes  and  a  relatively  small  bandwidth,  this  access  method  is  dismissed  as 
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unsuitable.  A  theoretical  variation  of  FDMA  is  spatial  frequency  reuse  based  on  a  cellular 
architecture  [36].  This  technique  limits  the  user  density  and  is  therefore  deemed 
impractical,  but  it  could  provide  answers  on  questions  regarding  interference  between 
clusters. 

TDMA  [23]  provides  the  user  with  the  full  available  bandwidth  by  allowing  only 
one  transmission  at  a  time.  The  downside  is  that  it  creates  an  inefficiency  because  of  the 
long  time  delays  required  in  the  underwater  channel.  Time  dispersion  of  the  signal  further 
requires  additional  guard  bands.  Fixed  time  slots  may  decrease  the  efficiency  even  further 
when  transmissions  are  shorter  than  the  allocated  time.  Polling,  or  interrogating  nodes  by 
a  master  node,  is  a  way  to  overcome  this  and  avoid  synchronization  issues  which  keeps 
the  complexity  of  nodes  low.  However,  it  introduces  additional  overhead  which  also 
decreases  the  efficiency. 

CDMA  [23]  actually  provides  random  access  for  users  since  it  allows  signal 
transmissions  that  overlap  both  in  frequency  as  in  time.  It  assigns  a  unique  pseudo¬ 
random  code  sequence  to  each  user  by  spreading  the  information  signal  across  the  entire 
frequency  band.  The  receiver  is  able  to  demodulate  the  simultaneous  transmitted  signals 
because  of  the  small  cross  correlation  that  the  code  sequences  have  with  each  other. 
Spreading  can  be  achieved  either  by  direct- sequence  spread  spectrum  (DSSS)  or 
frequency-hop  spread  spectrum  (FHSS).  FHSS  requires  less  complex  receivers  and  is 
more  robust  to  multiple  access  interference  than  DSSS  but  is  also  more  sensitive  to 
Doppler  shift  effects.  CDMA  performance  is  sensitive  to  the  relative  receive  power  of 
simultaneous  signals,  and  power  control  is  required  to  mitigate  this  sensitivity.  A  recent 
CDMA  experiment  [37]  has  demonstrated  that  low  complexity  receiver  algorithms  are 
realizable  and  effective.  Although  CDMA  appears  to  be  a  promising  technique  for 
underwater  communications,  especially  in  the  case  of  a  network  with  multiple  users  and 
moving  nodes  at  short  ranges  such  as  Seastar,  more  research  needs  to  be  done  in  this  field 
before  it  can  be  applied. 

Random  access  methods  like  ALOHA,  carrier  sense  multiple  access  (CSMA)  and 
multiple  access  with  collision  avoidance  (MAC A)  are  reviewed  in  [19,  22,  23,  34]. 

Peripheral  nodes  using  ALOHA  and  slotted  ALOHA  [22]  generally  do  not  “listen”  to  the 
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communications  channel  and  transmit  whenever  data  needs  to  be  transmitted. 
Acknowledgement  messages  (ACK)  report  the  reception  of  the  message.  CSMA  [22] 
aims  to  prevent  collisions  by  sensing  communications  activity  and  delaying  new 
transmissions  until  the  channel  is  clear.  However,  the  long  propagation  time  limits  the 
effectiveness  of  CSMA  for  acoustic  communications.  MACA  [22]  uses  request-to-send 
(RTS)  and  clear-to-send  (CTS)  messages  to  establish  communications  before  transmitting 
the  data  packets.  In  a  positive  acknowledgement  MACA  protocol,  if  no  ACK  message  is 
received  after  the  transmission  is  completed,  the  full  packet  will  be  retransmitted  until 
reception  is  acknowledged.  In  a  negative  acknowledgement  MACA  protocol,  the 
transmitter  assumes  success  unless  it  receives  a  repeat  request.  Seaweb  is  an  example  of 
successful  implementation  of  MACA  under  water.  The  RTS-CTS  messages  could  further 
be  used  as  probe  signals  for  adaptive  modulation  or  power  control.  Although  MACA 
reduces  the  amount  of  retransmissions  significantly,  it  introduces  additional  overhead 
prior  to  every  data  transmission. 

Although  random  access  methods  are  flexible,  they  are  not  very  suitable  under 
water  when  an  almost  continuous  flow  of  information  between  nodes  at  short  range  is 
expected.  The  large  amounts  of  collision  avoidance  overhead  or  retransmissions  will 
cause  large  delays  and  make  the  network  inefficient. 

Based  on  the  previous  outline,  we  shall  pursue  the  use  of  TDMA  as  the  favorable 
access  method  for  Seastar.  In  order  to  overcome  difficulties  regarding  synchronization 
and  predefined  time  slots,  and  to  avoid  the  need  for  synchronized  clocks,  it  is  necessary 
to  introduce  some  form  of  central  control.  This  might  be  provided  by  a  polling 
mechanism  or  a  token  to  be  passed  from  node  to  node.  This  issue  will  be  addressed  in  the 
section  that  discusses  the  network  layer.  In  the  meantime,  developments  in  the  field  of 
CDMA  in  the  underwater  environment  need  to  be  followed  closely  for  application  to 
Seastar. 

2.  CRC,  FEQ  and  SRQ 

Error  control  refers  to  mechanisms  to  detect  and  correct  errors  that  occur  in 
transmissions.  One  of  the  most  common  error  detection  mechanisms  is  the  cyclic 
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redundancy  check  (CRC).  CRC  is  described  in  detail  by  Stallings  [22]  and  is  based  on  the 
calculation  of  a  code  that  is  a  function  of  the  bits  being  transmitted.  This  code  is 
appended  to  the  information  packet  and  introduces  a  small  amount  of  overhead. 

Two  error  correction  mechanisms,  forward  error  correction  (FEC)  and  selective- 
reject  automatic  repeat  request  (SRQ),  will  be  briefly  discussed  from  a  Seastar 
perspective. 

One  approach  is  to  prevent  retransmission  by  introducing  redundant  bits  so  that 
the  receiver  is  capable  of  correcting  any  detected  errors.  This  is  the  principle  of  FEC. 
While  we  do  not  want  to  divert  towards  a  discussion  regarding  available  coding 
techniques  for  FEC,  it  may  be  obvious  that  more  redundancy  comes  at  a  cost.  The  term 
code  rate  which  is  related  to  FEC  refers  to  a  metric  that  expresses  the  overhead  required 
to  carry  data  at  the  same  data  rate  as  without  the  code.  Code  rates  of  1/2,  meaning  that 
twice  the  bits  are  required,  are  no  exception.  FEC  may  take  many  forms  and  tradeoffs 
regarding  overhead  versus  probability  of  error  should  be  considered. 


Node  A 


Node  B 


1.  Node  A  initiates  a 
link-layer  dialog  with 
Node  B. 

3.  Node  A  transmits  a 
4000-byte  Data  packet 
using  16  256-byte  sub¬ 
packets,  each  with  an 
independent  CRC. 


6.  Node  A  retransmits 
the  4  sub-packets 
specified  by  the  SRQ 
mask. 


8.  Node  A  retransmits 
the  1  sub-packet 
specified  by  the  SRQ. 


2.  Node  B  is  prepared  to  receive  a  large  Data 
packet  as  a  result  of  RTS/CTS  handshaking. 


4.  Node  B  receives  23  sub-packets  successfully; 
4  sub-packets  contained  uncorrectable  bit  errors. 

5.  Node  B  issues  an  SRQ  utility  packet,  including 
a  16-bit  mask  specifying  the  4  sub-packets  to  be 
retransmitted. 


7.  Node  B  receives  3  of  the  4  packets 
successfully  (future  implementation  of  cross-layer 
time-diversity  processing  will  recover  4  of  4).  B 
issues  an  SRQ  for  the  remaining  sub-packet. 

9.  Node  B  successfully  receives  and 
processes  Data  packet. 


Figure  24  An  example  of  selective  automatic  repeat  request  (SRQ)  (After  [38]). 
Retransmission  of  corrupted  sub-packets  continues  until  the  full  packet  has  been 

received  successfully. 
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SRQ  is  a  form  of  error  control  that  is  already  successfully  incorporated  in  Seaweb 
and  is  well  documented  by  Kalscheuer  [38].  SRQ  relies  on  the  detection  of  bit-errors  by 
the  receiver  using  CRC  and  results  in  retransmission  of  the  corrupted  data.  The  principle 
of  selectivity  refers  to  the  possibility  of  retransmitting  only  a  portion  of  the  message 
instead  of  the  full  message.  This  requires  that  the  data  packet  be  divided  into  smaller  sub¬ 
packets  each  padded  with  its  own  CRC  bytes.  The  disadvantage  of  SRQ  is  that  it  incurs 
latency  and  overhead. 

Both  FEC  and  SRQ  can  be  applied  simultaneously  as  has  been  done  for  Seaweb. 
Harris  et  al.  [3]  studied  the  combined  effects  of  applying  FEC  and  dividing  the  packet 
into  smaller  sub-packets.  Both  FEC  and  SRQ  have  proven  effective  and  are 
simultaneously  suitable  for  Seastar  applications.  The  effects  of  sub-packet  size  and  SRQ 
on  the  network  performance  is  discussed  in  Chapter  VII. 

B.  NETWORK  LAYER 

The  network  layer  performs  routing  functions  to  enable  the  transfer  of  data 
packets  from  a  source  to  a  destination  via  one  or  more  nodes.  It  is  responsible  for  setting 
up,  maintaining  and  terminating  connections  and  involves  knowledge  about  the  structure 
of  the  network.  A  topology  defines  how  end  points  of  a  network  are  interconnected  and 
how  data  flows.  Optimizing  the  topology  is  essential  in  terms  of  capacity,  energy 
consumption  and  reliability  of  the  network.  We  focus  our  discussion  of  the  network  layer 
on  suitable  topologies  to  describe  the  Seastar  network  structure  and  data  flow. 

Some  common  basic  topologies  are  bus,  star,  ring  and  tree  [22].  Seaweb  is 
normally  structured  with  a  tree  topology.  For  Seastar,  we  narrow  our  candidates  to  the 
star  and  ring  topologies,  although  hybrid  forms  might  be  options  as  well. 

A  star  topology  typically  connects  all  nodes  to  a  common  central  node.  This 
central  node  acts  either  as  a  hub  that  collects  and  fuses  information  that  is  received,  or  it 
acts  as  a  switching  device  where  it  relays  information  from  one  node  to  another.  In  a  ring 
topology  the  network  consists  of  a  set  of  repeaters  connected  by  point-to-point  links 
forming  a  closed  loop.  Information  flows  in  any  or  both  directions.  Both  topologies  have 
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one  crucial  shortcoming:  a  single  point  of  failure  at  the  central  node  for  the  star  or  any  of 
the  nodes  in  a  ring.  We  cannot  tolerate  full  network  failure  and  mechanisms  will  need  to 
be  implemented  to  avoid  it. 


o 

Figure  25  Star  versus  ring  topology 


1.  Star  Topology 

For  Seastar  to  operate  in  conjunction  with  Seaweb,  the  star  topology  would 
function  as  follows.  The  central  node  receives  information  from  the  peripheral  nodes, 
fuses  it  and  sends  it  as  an  information  packet  through  Seaweb.  The  central  node  also 
behaves  as  a  local  command-and-control  (C2)  node  for  Seastar.  A  polling  mechanism 
serves  to  avoid  packet  collisions,  and  error  correction  in  the  form  of  SRQ  is  issued  as 
necessary  from  the  central  node  to  the  peripheral  nodes.  The  polling  mechanism,  which 
consists  of  a  short  utility  packet  containing  address  information,  invites  peripheral  nodes 
to  transmit  data  if  available.  Control  information  such  as  preferred  output  level  or  bit  rate 
could  be  included.  The  downside  of  this  mechanism  is  that  it  introduces  overhead  but  it 
makes  unnecessary  the  need  for  handshaking  (RTS-CTS)  and  explicit  acknowledgements 
(ACK).  None  of  the  peripheral  nodes  need  to  receive  information  from  other  peripheral 
nodes  which  simplifies  both  the  network  logic  as  well  as  the  modem  hardware.  In  order 
to  reduce  the  complexity  of  the  peripheral  modems  even  further,  the  brief  C2  messages 


48 


are  transmitted  at  relatively  low  data  rate  and  are  reliably  received  with  a  simple 
demodulator.  Conversely,  the  data  transmissions  from  peripheral  to  central  node  are  done 
at  high  bit  rates. 


The  star  topology  is  less  susceptible  to  network  failure  than  the  ring.  The  central 
node,  required  to  run  the  network,  is  its  weak  point  and  unfortunately  the  only  way  to 
avoid  full  network  failure  in  case  of  central  node  malfunction  is  to  have  a  backup  node 
available  in  the  network  that  could  assume  its  duty.  In  the  close  presence  of  multiple 
clusters  this  may  be  achieved  by  reassigning  the  peripheral  nodes  to  neighboring  LANs. 
Another  option  is  to  have  a  mobile  node  available  that  could  replace  the  failed  central 
modem.  In  summary,  backup  options  would  either  require  significant  advance  planning 
or  redeployment  of  spare  hardware. 

Once  the  choice  for  a  topology  is  made,  it  is  necessary  to  determine  the  most 
efficient  strategy  to  operate  the  network.  This  is  done  with  the  aid  of  a  simulation  tool 
developed  for  this  purpose  and  which  is  documented  in  Chapter  VI.  Early  simulation 
experiments  narrowed  the  number  of  strategy  options  for  a  star  topology  down  to  two. 
Both  are  described  in  more  detail  now. 


Figure  26  Candidate  Seastar  star  topology  strategies  are  P1D  (left),  which  allows  SRQ 
expressed  by  red  arrows  and  PIE  (right)  that  does  not  use  this  error  correction 
feature.  Poll  and  data  transmissions  are  expressed  by  green  and  black  arrows, 


respectively. 


49 


a. 


Star  Topology  Strategy  Type  P1D 


Strategy  P1D,  as  it  shall  be  defined  here,  is  graphically  explained  in  Figure 
27.  It  uses  a  short  utility  message,  represented  in  the  figures  by  a  green  arrow,  which  is 
transmitted  omnidirectionally  from  the  central  node  to  poll  a  specific  peripheral  node. 
Upon  reception,  this  node  replies  by  omnidirectionally  transmitting  its  data,  preceded  by 
a  header  containing  information  regarding  the  contents  of  the  message  such  as  source 
address,  sequence  number,  message  length  and  number  of  sub-packets.  If  the  CRC  of  a 
specific  sub-packet  fails,  an  SRQ,  represented  in  the  figures  by  a  red  arrow,  is  initiated 
and,  if  necessary,  repeated  until  all  sub-packets  have  been  successfully  received  or  the 
maximum  number  of  SRQ  retries  has  been  reached.  Once  the  full  data  packet  has  been 
received  by  the  central  node  it  processes  it  and  polls  the  next  modem.  The  polling  will 
continue  uninterrupted. 


Successful  Poll 


central 


peripheral 


CRC+SRQ  Fail 

central  peripheral 


Poll  Fail 


WAIT 


central 


WAIT 


peripheral 


Packet  out  of  Sequence 

central  peripheral 


ACK  Fail 


Rec  (2, 
Exp(1. 
SRQ(1 


central 


peripheral 


Re-txmit 
At  140bps 

WAIT  ACK 


Figure  27  Graphical  explanation  of  the  P1D  strategy  as  described  in  IV. B.  1  .a. 
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If  the  poll  or  SRQ  utility  packet  is  corrupted,  no  data  transmission  ensues 
and  a  time-out  period  for  reception  at  the  central  node  indicates  that  something  has  gone 
wrong.  In  this  case  a  retransmission  of  the  utility  packet  is  issued  until  either  the  data 
packet  is  received  or  a  maximum  number  of  SRQ  or  poll  retries  has  been  reached.  In  the 
case  of  maximum  SRQ,  the  packet  is  aborted  and  considered  lost.  In  the  case  of  a 
maximum  achieved  number  of  polls,  the  peripheral  node  maintains  track  of  the  data  and 
its  sequence  number  for  transmission  at  the  next  cycle.  At  the  next  cycle,  the  choice  can 
now  be  made  for  the  central  modem  to  either  ask  for  the  latest,  most  up-to-date  sequence 
number  (so  implicitly  aborting  the  previous  number)  or  to  have  it  issue  an  SRQ  for  full 
retransmission.  In  this  last  case,  as  well  as  in  unforeseen  situations  where  a  packet  ends 
up  out  of  sequence,  an  explicit  ACK  for  reception  is  issued  by  the  central  node. 

b.  Star  Topology  Strategy  Type  PIE 

Strategy  PIE  is  based  on  P1D  but  does  not  perform  sub-packet  recoveries. 
The  motivation  for  this  variation  is  to  support  network  operations  where  low  latency  is  a 
higher  priority  than  transmission  reliability,  thus  favoring  a  low  amount  of  overhead.  All 
corrupted  packets  are  consequently  aborted.  PIE  does,  however,  poll  again  upon  failure 
but  this  is  limited  to  one  additional  attempt.  The  description  for  PIE  is  therefore  the  same 
as  for  P1D  but  excludes  SRQ. 
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Figure  28  Graphical  explanation  of  the  PIE  strategy  as  described  in  IV. B.  1  .b. 
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2.  Ring  Topology 


Although  we  will  refer  to  a  ring  topology,  the  idea  actually  diverges  from  the 
traditional  ring  since  the  central  node  is  included.  This  is  not  only  required  to  connect 
Seastar  to  Seaweb  but  it  also  provides  the  possibility  to  perform  centralized  C2  duties  in 
case  of  network  failure.  The  main  difference  with  the  star  topology  is  the  absence  of  a 
polling  mechanism  from  the  central  modem.  Instead,  a  token  is  passed  between 
neighboring  peripheral  nodes  without  interruption  from  the  central  modem.  Not  only  does 
this  reduce  overhead  but  it  also  reduces  the  energy  consumption  at  the  central  modem.  A 
peripheral  node  is  only  allowed  to  transmit  data  upon  reception  of  a  token  that  is  received 
from  the  previous  node  in  the  cycle.  Because  the  token  is  transmitted  omnidirectionally, 
address  knowledge  between  neighboring  nodes  is  required  and  included  in  the  token. 
Data  packets  are  also  transmitted  omnidirectionally  but  processed  by  the  central  node 
only.  The  data  transmission  is  padded  by  the  updated  token,  which  cues  the  next  modem 
to  transmit  data.  It  is  obvious  that  a  ring  topology  requires  not  only  communications 
between  central  and  peripheral  nodes  but  also  between  neighboring  peripheral  nodes, 
which  makes  the  ring  less  suitable  for  independently  moving  nodes. 


Figure  29  Candidate  Seastar  ring  topology  strategies  are  T2B  (left),  which  does  not  use 
SRQ,  and  T3A  (right),  which  allows  SRQ  as  an  integrated  message  within  the 
token,  updated  by  the  central  node  every  cycle.  Token  transmissions  are 
expressed  either  as  green  or  as  red-green  arrows  and  data  transmissions  as  black 

arrows,  respectively. 
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As  with  the  star  topology,  RTS-CTS  and  ACK  messages  are  not  required  but 
introducing  SRQ  or  token  retransmission  is  more  complicated  since  C2  occurs  on  two 
levels.  In  case  of  a  corrupted  token,  retransmission  would  have  to  be  coordinated  between 
neighboring  nodes  whereas  corruption  of  sub-packets  is  handled  between  central  and 
peripheral  nodes.  This  complicates  the  network  logic  and  forms  the  basis  of  creating  two 
variations  on  the  ring  theme  as  described  in  the  following  subsections. 


a.  Ring  Topology  Strategy  Type  T2B 


Strategy  T2B  involves  passing  a  token  amongst  the  peripheral  nodes  and 
can  be  compared  to  PIE  in  the  sense  that  it  does  not  provide  SRQ.  The  central  node 
receives  and  processes  all  packets  that  are  received  successfully  and  aborts  all  corrupted 
packets.  In  case  of  a  corrupted  token  the  network  would  normally  fail  completely. 
However,  the  central  node  will  sense  that  no  data  is  transmitted  and  will  retransmit  the 
token  to  the  last  expected  address  after  a  time-out  period.  If  still  no  data  packet  is 
received  the  central  node  will  reinitiate  the  token  again  but  now  it  is  addressed  at  the  next 
peripheral  node  in  the  cycle.  Figure  30  provides  an  overview  of  the  network  logic. 


Successful  Transmission  CRC  Fail  Token  Fail 

Central  Periph.1  Periph.2  Central  Periph.1  Periph.2  Central  Periph.1  Periph.2 


Figure  30  Graphical  explanation  of  the  T2B  strategy  as  described  in  IV.B.2.a. 


b.  Ring  Topology  Strategy  Type  T3A 

An  alternative  ring  strategy  introduces  an  additional  hop  in  the  ring  by 
passing  the  token  though  the  central  node  and  is  referred  to  as  T3A.  During  a  cycle,  the 
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central  node  stores  information  regarding  unsuccessful  sub-packet  transmission  from 
each  peripheral  node.  The  token,  now  expressed  as  a  red-green  arrow,  is  designed  to 
carry  additional  information  or  instructions,  such  as  SRQ,  and  is  updated  by  the  central 
node.  The  token  carries  this  information  with  it  in  the  ring  and  delivers  it  at  the  target 
node.  The  length  of  the  token  utility  packet  therefore  scales  with  the  number  of  nodes  in 
the  networks  but  clever  design  can  reduce  the  additional  overhead.  Upon  reception  of  an 
SRQ,  the  peripheral  node  will  both  retransmit  corrupted  (sub-)packets  and  transmit  new 
data  in  the  same  cycle.  Unsuccessful  retransmissions  will  generate  no  new  retransmission 
because  of  long  latencies  for  that  specific  message  and  the  full  packet  will  be  aborted. 
The  same  time-out  logic  as  with  T2B  is  implemented  in  case  of  token  failure.  Figure  31 
summarizes  the  logic  of  T3A. 

Note  that  with  the  graphical  descriptions  of  P1D  and  T3A,  an  unsuccessful 
poll  or  token  generates  a  packet-out-of-sequence  situation.  This  just  occurs  for  simulation 
purposes.  Actual  implementation  could  include  either  packet  abortion  or  retransmission 
in  the  subsequent  cycle. 
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Figure  31  Graphical  explanation  of  the  T3A  strategy  as  described  in  IV.B.2.b. 

54 


V.  SEASTAR  PROTOTYPE  IMPLEMENTATION  AND  SEA 

TESTING 

A.  PROTOTYPE  IMPLEMENTATION 

A  Seastar  prototype  was  developed  to  test  the  concept  of  a  centralized  network 
with  through-water  acoustic  links.  The  following  goals  formed  the  basis  for  the  Seastar 
prototype: 

•  Verify  suitability  of  asymmetric  acoustic  links  in  air  and  water, 

•  Develop  a  prototype  network,  demonstrate  the  feasibility  in  air  and  provide 
initial  performance  metrics, 

•  Demonstrate  the  feasibility  in  water  and  provide  quantitative  and  qualitative 
analysis. 

The  first  two  goals  were  achieved  by  performing  experiments  in  the  anechoic 
chamber  and  the  anechoic  water  tanks  at  NPS.  The  last  goal  was  achieved  by  an 
experiment  as  part  of  AUV  Fest  2007  in  Panama  City,  FL. 

1.  Asymmetric  Link  Experiment 

For  the  asymmetric  link  experiment,  a  commercially  available  Teledyne  Benthos 
ATM-885  subsea  modem,  an  ATM-891  deck  box  and  an  AT-408  omnidirectional 
transducer  were  used.  Both  the  ATM-885  and  ATM-891  were  uploaded  with  standard 
commercial  firmware  version  5.5.  The  modems  operate  in  the  9-14  kHz  band  and  are 
designed  to  communicate  over  distances  up  to  5  km.  The  modulation  type  can  be  set  to 
either  multi-channel  MFSK  with  bit  rates  varying  from  140  bits/s  to  2400  bits/s  or  PSK 
with  bit  rates  varying  from  2560  bits/s  to  15360  bits/s.  Transmit  power  levels  or  source 
levels  can  be  set  at  164-185  dB  re  1  pPa  @  1  m  in  water  which  corresponds  to  102-123 
dB  re  20  pPa  @  1  m  in  air.  Communication  ranges  in  the  anechoic  water  tank  varied 
from  10  cm  to  4  m  whereas  ranges  in  the  anechoic  chamber  varied  from  10  cm  to  1  m. 
Interaction  with  both  the  ATM-885  as  well  as  the  AT-408  through  the  deck  box  was 
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established  by  connecting  the  RS-232  feeds  on  the  modems  to  two  USB  ports  on  an  HP 
Pavilion  DV5000  laptop  computer.  IOGEAR  USB-to-serial  adapters  were  used  to 
connect  the  RS-232  devices  to  the  USB  ports.  Symantec  Procomm  Plus  provided  a 
graphical  user  interface  (GUI)  to  interact  with  the  modems. 

One  interpretation  of  an  asymmetric  link  was  tested  easily.  Transmitting  short  (9- 
byte)  control  messages  from  the  deck  box  to  the  ATM-885  modem  followed  by  a  long 
(up  to  4096-byte)  message  reply  was  trivial.  The  next  step  was  to  test  asymmetry  with 
respect  to  bit  rate.  Both  in  air  and  water,  transmitting  at  the  lowest  available  bit  rate  (140 
bits/s)  and  replying  at  the  highest  possible  bit  rate  for  MFSK  (2400  bits/s)  produced  few 
problems  although  some  transmissions  failed  at  2400  bits/s.  Transmitting  messages  at 
lower  bit  rates  (up  to  1200  bits/s)  using  FEC  and  coding  was  never  a  problem,  which 
demonstrates  the  benefits  of  applying  error  correction  techniques. 

The  last  asymmetry  that  was  tested  involved  further  increment  of  the  bit  rate  by 
switching  to  PSK.  Some  occasional  transmission  successes  at  2560  bits/s  were  achieved 
but  this  was  hardly  enough  to  make  it  feasible  for  practical  application.  Higher  PSK  bit 
rates  with  this  setup  failed  in  every  attempt. 


Figure  32  Experimental  setup  for  asymmetry  tests  as  described  in  this  section. 

The  overall  conclusion  of  the  first  experiment  is  that  asymmetric  MFSK 
transmission  using  commercially  available  modems  is  practical  for  Seastar  prototype 
purposes.  However,  transmitting  at  even  higher  bit  rates  using  PSK  modulation  could  not 
be  achieved  with  the  same  equipment  and  was  therefore  found  not  suitable  for  prototype 
implementation. 
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2. 


Seastar  Prototype  Development  in  Air 


Once  the  asymmetry  possibilities  were  known,  the  Seastar  prototype  could 
proceed.  The  ATM-891  deck  box  and  AT-408  transducer  combination  represented  the 
central  node  and  five  ATM-885  modems  served  as  peripheral  nodes.  An  unsuccessful 
attempt  was  made  to  use  a  Brirel  and  Kjaer  PULSE  analyzer  for  impulse  response  and 
frequency-time  measurements  and  at  the  same  time  have  it  function  as  a  tool  to  trigger 
recordings  by  means  of  a  matched  filter.  The  equipment  was  later  replaced  by  a 
G.R.A.S.-type  40AF  free  field  microphone  and  type  26AK  1/2"  pre-amplifier 
combination,  connected  to  the  laptop  and  powered  by  a  G.R.A.S.-type  12AA  module. 
The  application  that  was  used  to  perform  the  time-frequency  spectrum  recordings  and 
analysis  was  Spectrogram  version  15. 1.1 


Figure  33  Experimental  setup  for  Seastar  prototype  in  anechoic  chamber  as  described  in 

this  section. 

In  a  later  phase  of  the  experiment  the  AT-408  transducer  was  replaced  by  one  of 
the  peripheral  modems  as  can  be  seen  in  Figure  34.  This  replacement  had  no  further 
impact  on  the  experiment.  The  laptop  was  always  connected  to  the  central  node  and  one 
of  the  peripheral  nodes  and  served  as  a  GUI  to  send  command  messages,  manipulate 
modem  and  network  settings,  and  provide  real-time  feedback  on  transmissions. 


1  Spectogram  v.  15.1,  Visualization  Software  LLC,  http://www.visualizationsoftware.com/gram.html. 
Accessed  2  December  2007. 
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The  topology  that  was  most  easy  to  create  with  the  available  equipment  was  a  star 
topology.  A  ring  topology  would  have  required  software  modification  in  the  modems. 
The  first  step  was  to  determine  a  way  to  implement  a  polling  mechanism.  Fortunately  an 
existing  9-byte  utility  packet  was  found  suitable  to  perform  this  function.  The  ASCII 
command  “ATSBT/z”,  where  n  refers  to  a  modem  address  was  originally  developed  to 
acoustically  order  modem  address  n  to  transmit  the  contents  of  its  data  buffer.  The  data 
buffer  is  usually  filled  with  data  from  a  sensor  that  is  hooked  up  to  the  serial  port.  For  our 
purposes,  an  1850-byte  test  message  was  manually  uploaded  and  stored  in  the  buffer  of 
all  peripheral  modems  and  resided  there  until  it  was  manually  erased. 


Figure  34  Seastar  prototype  setup  in  NPS  anechoic  chamber  showing  one  central  node 
and  four  peripheral  nodes.  The  range  between  the  peripheral  nodes  is 

approximately  1.5  m. 

We  now  had  a  9-byte  polling  message  (AT$BTn)  to  poll  any  modem  and  have  it 
respond  by  transmitting  an  1850-byte  data  packet  that  was  divided  into  eight  256-byte 
sub-packets,  a  Benthos  modem  feature.  To  introduce  the  asymmetric  link,  the  poll  was  set 
to  be  transmitted  at  140  bits/s,  followed  by  a  data  packet  transmission  at  800  bits/s.  The 
next  step  was  to  automate  the  polling  mechanism.  This  required  an  algorithm  that  had  to 
run  from  an  external  CPU  that  was  connected  to  the  central  modem  through  the  RS232 
connection.  Since  the  algorithm  had  to  be  installed  on  a  UNIX-like  driven  CPU  during 
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the  follow-on  experiment  at  sea,  the  choice  was  made  to  exchange  the  laptop  computer 
for  a  Linux  machine.  Since  we  abandoned  the  PSK  modulation,  there  was  no  need  to 
continue  working  with  the  commercial  code  and  all  modems  were  uploaded  with  the 
Seaweb  source  code,  version  17.3,  providing  the  modems  with  extended  network 
features,  such  as  SRQ,  that  would  be  useful  in  our  prototype  Seastar  implementation. 

The  C  algorithm,  as  shown  in  Appendix  A,  is  a  modification  to  the  original 
software  used  on  the  Seaweb  Racom  (radio/acoustic  communications)  gateway  buoys  to 
allow  interaction  with  the  Seaweb  network.  The  polling  algorithm  includes  several 
recovery  features  and  additional  delays  to  prevent  network  failure  and  performs  an 
automatic  restart  in  case  of  a  full  network  crash.  The  challenge  lay  in  the  fact  that  the 
newly  developed  polling  algorithm  needed  to  work  in  conjunction  with  the  existing 
Seaweb  modem  firmware.  For  example,  the  polling  has  to  be  suspended  whenever  a 
transmission  is  corrupted  to  allow  SRQ.  Upon  successful  transmission,  the  polling 
mechanism  must  then  automatically  retake  control  and  continue  the  polling  cycle. 

Handshaking  through  RTS-CTS  as  well  as  explicit  acknowledgements  through 
ACK  utility  packets  was  disabled  with  SRQ  enabled  by  setting  the  modem’s  S -registers 
as  follows:  S33=3,  S34=0,  S57=0.  With  these  settings,  handshaking  only  occurs  upon 
network  initialization  and  whenever  the  central  modem  comes  out  of  low  power  state.  A 
10-second  delay  after  data  transmission  was  built  in  to  avoid  overlap  of  polling  and 
retransmission  of  full  packets  in  case  of  a  packet-out-of-sequence  situation.  As  a  final 
recovery  mechanism,  a  10-minute  timer  was  inserted  in  the  code  to  enable  an  automatic 
network  restart  in  case  of  full  network  failure. 

Upon  detection  of  multiple  simultaneous  transmissions,  the  central  node  ceases 
polling  for  10  minutes  to  allow  all  modems  to  assume  a  low-power  state  and,  in  doing  so, 
clear  all  sequence-number  memories.  The  polling,  preceded  by  a  new  handshake, 
automatically  resumes  after  this  silent  period.  A  spectrogram  of  a  single  round-trip 
transmission  containing  a  poll  and  a  data  reply  can  be  seen  in  Figure  35. 
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poll  data 

Figure  35  Time  (horizontal  axis)  and  frequency  (vertical  axis)  recording  in  water  of  9- 
byte  poll  at  140  bits/s  followed  by  1850-byte  data  transmission  at  800  bits/s. 

With  these  settings,  the  network  is  able  to  operate  under  the  influence  of  physical- 
layer  faults.  We  will  refer  to  a  single  round-trip-time  (RTT)  as  the  time  required  for 
transmitting  a  poll  followed  by  a  data  transmission  including  delays.  An  average  single 
RTT  without  retransmissions  was  measured  to  be  34.5  seconds.  The  exact  RTT  depended 
on  random  delays  that  are  introduced  by  the  Benthos  modems  as  a  built-in  feature  but  the 
deviation  was  never  more  than  3%  of  the  average  value.  For  five  peripheral  modems  this 
would  mean  that  the  average  cycle  time  would  be  173  s.  This  value  was  found  to  be  a 
useful  metric  since  it  indicates  the  mean  time  between  data  transmissions  from  a 
particular  Seastar  modem.  We  will  further  refer  to  the  cycle  time  as  latency  with  units  of 
seconds.  The  latency  is  also  affected  by  the  amount  of  retransmissions  required  and 
therefore  implicitly  indicates  the  reliability  of  a  topology.  If  SRQ  is  disabled,  however, 
the  latency  will  remain  constant  at  an  unsuccessful  transmission  but  the  reliability  drops. 
A  second  metric  that  does  account  for  this  and  can  easily  be  measured  is  the  number  of 
dropped  packets.  It  is,  however,  desirable  to  evaluate  this  number  independent  of  the 
amount  of  packets  that  were  transmitted.  We  therefore  normalize  the  number  of  packets 
by  expressing  it  as  a  ratio  of  the  number  of  unsuccessfully  transmitted  packets  to  the  total 
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number  of  packets  as  a  percentage.  From  a  network  efficiency  perspective,  it  is  useful  to 
know  the  efficiency  or  utilization  of  the  channel.  This  third  metric  is  defined  as  the  ratio 
of  time  Ti  required  to  transmit  information  bits  over  the  total  time  T,  required  to  perform 
this  transmission.  The  total  time  includes  overhead  caused  by  headers,  CRC,  redundancy, 
retransmissions,  and  necessary  polling  or  token  utility  packets.  As  an  example,  7,  for 
1850  bytes  at  800  bits/s  would  be  18.5  s,  but  as  was  shown  before,  Tt  is  34.5  s.  The 
dimensionless  utilization  is  therefore  18.5  s  divided  by  34.5  s  which  is  0.536.  In  other 
words,  only  54%  of  the  channel  availability  was  efficiently  used  to  transmit  information. 
The  last  metric  is  related  to  the  channel  utilization  but  expresses  the  efficiency  in  a  more 
operational  sense.  It  is  defined  as  the  number  of  transmitted  information  bits  per  RTT. 
This  metric  is  further  referred  to  as  information  throughput  and  has  units  of  bits/s.  As  an 
example  we  will  use  the  same  data  as  above  and  determine  the  information  throughput 
for  our  experimental  setup  to  be  8  bits/byte  times  1850  bytes  divided  by  34.5  s  which  is 
430  bits/s.  In  other  words,  although  800  bits/s  was  the  physical-layer  bit  rate,  this  specific 
experimental  setup  only  achieves  a  maximum  network-layer  bit  rate  of  430  bits/s,  which 
is  again  54%. 

Conclusively  we  can  state  that  a  first  Seastar  prototype,  using  a  polling 
mechanism,  was  successfully  developed,  tested  in  air  and  analyzed.  The  analytical 
metrics  that  were  found  useful  are:  information  throughput,  channel  utilization,  latency, 
and  dropped  packets.  These  metrics  are  used  throughout  the  rest  of  this  research.  For  our 
in-air  experimental  network,  the  following  values  were  found:  information  throughput 
430  bits/s,  utilization  0.536,  latency  173  s  and  a  zero  percentage  of  dropped  packets, 
recognizing  that  these  values  were  obtained  under  almost  perfect  test  conditions  by  using 
the  anechoic  chamber.  Now,  we  analyze  the  performance  of  this  version  of  the  Seastar 
prototype  while  deployed  in  realistic  conditions  at  sea. 

B.  EXPERIMENT  PLAN 

In  June  2007,  a  Seastar  prototype  was  tested  in  water  during  the  AUV  Fest 
demonstration  at  St.  Andrews  Bay,  FL.  The  goal  was  to  demonstrate  the  feasibility  in 
water  of  the  prototype  described  in  the  previous  section  and  provide  a  quantitative  and 
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qualitative  analysis.  The  plan  consisted  of  deploying  the  network  in  shallow  water  in  a 
moderate  shipping  area  to  observe  influences  of  natural  and  man-made  interference  on 
the  network  performance.  To  measure  network  performance  quantitatively  in  metrics  of 
information  throughput,  channel  utilization,  latency  and  dropped  packets  it  was  necessary 
to  use  equipment  capable  of  recording  number  and  status  of  received  poll  and  data 
packets  as  well  as  SRQ  utility  packets,  all  tagged  with  time  stamps.  For  a  qualitative 
analysis  it  was  required  to  associate  the  successful  and  anticipated  unsuccessful 
transmissions  to  the  channel  conditions,  possible  noise  sources,  and  network  settings. 
Direct  access  to  the  network  to  manipulate  settings  and  observe  related  performance 
would  allow  additional  quantitative  and  qualitative  analysis  data  and  could  provide 
calibration  data  for  future  network  simulations. 

The  available  hardware  consisted  of  five  Teledyne  Benthos  ATM-885  modems 
that  would  serve  as  peripheral  nodes  and  a  central  Racom  gateway  buoy  that  would 
perform  the  function  of  central  node  and  gateway  to  the  Seastar  network.  To  achieve  this, 
the  Racom  was  equipped  with  a  Teledyne  Benthos  ATM-885RPCB  modem  board,  an 
AT-408  omnidirectional  transducer,  Iridium  satellite  communications  and  FreeWave 
radio.  It  further  contained  a  central  processing  unit  (CPU)  that  was  used  to  upload  the 
polling  algorithm  as  well  as  the  original  algorithm  to  enable  manual  network  access.  Not 
only  did  this  allow  changing  network  parameters  but  it  also  permitted  troubleshooting 
and  uploading  the  C  program  in  case  debugging  of  the  code  was  required.  Last,  the 
Racom  allowed  local  storage  of  network  data  which  formed  a  backup  in  case  of  radio 
communications  failure.  Remote  monitoring  of  the  network  would  occur  from  a  Seaweb 
server  [39]  at  Naval  Surface  Warfare  Center  (NSWC)  Panama  City,  FL.  To  ensure 
qualitative  analysis,  a  moored  sonobuoy,2  capable  of  recording  raw  acoustic  data  such  as 
network  transmissions,  shipping,  and  other  interference  (e.g.,  see  [40]),  would  be 
deployed  within  200  m  of  the  central  modem.  The  data  recorded  by  the  sonobuoy  were 
transmitted  to  a  laptop  ashore  and  could  be  analyzed  real  time  by  the  Spectrogram 
application.  Analysis  was  further  informed  by  conductivity-temperature-density  (CTD) 

2  SeaLandAire  Technologies,  Inc.  http://www.sealandaire.com/currenptojects.php.  Accessed  2 
Decemeber  2007. 
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profiles  and  other  local  data  at  the  experiment  site,  such  as  wind  and  visual  and/or  surface 
radar  tracks,  that  were  collected  both  by  SPAWAR  Systems  Center  San  Diego  and  US 
Navy  METOC  personnel. 


Figure  36  Upper  picture  shows  a  peripheral  modem  attached  to  a  weight,  acoustic 
release  and  a  floating  body  for  vertical  positioning  and  recovery.  Lower  pictures 
show  the  sonobuoy  (left)  and  Racom  buoy  (right). 


C.  EXPERIMENT  SETUP 

1.  St.  Andrews  Bay 

St.  Andrews  Bay  is  connected  to  the  Gulf  of  Mexico  and  is  part  of  the  intra¬ 
coastal  waterway  system.  The  Seastar  test  site  was  located  1  km  east-southeast  of  the 
main  commercial  port,  as  can  be  seen  in  Figure  37.  The  water  depths  at  the  site  vary  from 
8  m  to  13  m  and  the  bottom  consists  of  an  acoustically  absorptive  mud/silt  composition. 
Surface  temperatures  during  the  experiment  were  generally  over  30  degrees  Celsius  and  a 
moderate  southwest  breeze  usually  developed  in  the  afternoon  causing  an  average  sea 
state  of  1  (0-0.1  m). 
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AUVfest/Unet  2007  Trials 

St.  Andrew  Bay,  Panama  City,  Florida 
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Figure  37  Geographic  overview  of  AUV  Fest  /  UNET  test  site  showing  the  Seastar 
prototype  network  geometry  in  combination  with  the  depth  contours  in  meters. 
Panama  City’s  main  port  lies  1  km  west-northwest  of  the  central  node. 

Occasional  tropical  rain  showers  causing  severe  variations  in  the  sound  velocity 
profile  were  expected;  however,  none  occurred  during  the  actual  data  collecting  phase. 
Two  series  of  CTDs  taken  prior  and  during  deployment  resulted  in  sound-speed  profiles 
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(SSPs)  as  shown  in  Figure  38.  The  absence  of  heavy  rain  and  wind  during  the  week 
caused  the  SSP  at  the  test  site  to  remain  stable  although  a  negative  gradient  developed 
near  the  surface. 
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Figure  38  SSPs  taken  at  the  test  site  show  only  a  slight  increase  in  temperature  over  a 
period  of  a  week  and  the  development  of  a  negative  gradient  near  the  surface. 

Sound  propagation  predictions  based  on  the  SSPs  for  June  7,  one  of  the  actual 

data  collection  days,  are  presented  in  Figure  39.  This  figure  was  generated  by  a  Matlab 

application  developed  by  Torres  [41]  that  uses  the  Bellhop  Gaussian  beam  tracing 

acoustic  propagation  model.  Torres  demonstrated  that  Bellhop  is  suitable  for  modeling 

high-frequency  acoustic  propagation  in  shallow  water  and  performed  several  case  studies 

for  St.  Andrews  Bay.  Even  though  our  experiment  used  medium  frequencies,  the  model 

provided  useful  data  for  determining  the  most  suitable  deployment  depth  for  the  modems 

to  ensure  communications.  The  Bellhop  model  shows  a  downward  refracting 

communications  channel  and  surface  and  bottom  bounce  paths.  The  almost  isospeed 

channel  also  supports  direct-path  propagation,  which  is  most  favorable  since  it 
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experiences  the  least  transmission  loss  of  all  multi-paths.  The  bottom-surface  interactions 
induce  expected  multi-path  time  dispersion  of  23  ms. 
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Figure  39  Bellhop  predictions  for  7  June  at  a  location  between  the  Racom  and  T7  show  a 
downward  refracting  communications  channel  that  allows  direct  path.  Multi-path 
arrivals  due  to  bottom  and  surface  interactions  are  also  expected. 

The  average  multi-path  delay  as  measured  by  the  modems  was  0.72  ms.  Compared  to  the 
predicted  maximum  of  23  ms,  we  can  conclude  that  the  main  propagation  path  during  the 
experiment  was  direct  path  and  interference  due  to  multi-path  delay  is  not  considered  to 
have  been  a  significant  factor.  The  nearly  stationary,  almost  isospeed  channel  conditions 
therefore  made  the  environment  at  the  test  site  well  suited  for  underwater  acoustic 
communications. 

Noise  sources  consisted  mainly  of  shipping,  wind  and  sea  life.  Shipping  noise  was 
episodic,  arising  from  small  private  vessels  and  occasional  commercial  vessels.  Traffic 
associated  with  AUV  Fest  also  contributed  to  shipping  noise.  The  most  significant  noise 
source  in  our  operating  band,  however,  appeared  to  be  interference  from  other 
experiments  in  the  bay  that  used  Teledyne  Benthos  modems. 

The  maximum  observed  wind  during  the  actual  data  taking  was  15  knots  which, 
according  to  the  Wenz  curves  [17],  leads  to  ambient  noise  levels  of  47-50  dB  on  the  9- 
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14  kHz  band.  Although  the  effect  of  noise  produced  by  shipping  generally  diminishes 
above  1  kHz  as  shown  in  Figure  6,  interference  from  vessels  crossing  the  network  at 
close  range  was  observed. 

Noise  generated  by  shrimps  and  other  sea  life  was  observed  and  recorded  but  no 
causal  interference  could  be  verified  during  the  trials. 

Variability  in  the  noise  was  mainly  dependent  on  the  activity  of  the  other  Seaweb 
experiments  being  conducted  in  the  bay  and  was  not  noticeably  influenced  by  natural 
conditions  at  all.  Overall,  the  propagation  and  noise  conditions  were  favorable  for  testing 
the  Seastar  prototype  network. 

2.  Network  Setup 

All  five  peripheral  modems  were  deployed  at  ranges  of  500  m  from  the  central 
node  (Figure  37)  causing  an  average  one-way  propagation  delay  of  0.3  s.  The  geometry 
of  the  channel  and  presence  of  other  networks  in  the  vicinity  did  not  allow  a  symmetric 
setup  but  this  was  not  a  requirement  for  the  polling  strategy.  In  accordance  with  the 
Bellhop  propagation  predictions,  the  modem  transducers  were  positioned  at  3  m  from  the 
bottom.  The  transmit  power  levels  of  the  central  node  and  peripherals  were  set  to  179  dB 
re  1  pPa  @  1  m.  The  acoustic  baud  rates  of  the  peripheral  nodes  and  central  node  were 
set  to  800  bits/s  and  140  bits/s,  respectively.  The  poll  and  data  message  as  well  as  the 
SRQ,  RTS-CTS  and  ACK  settings  (S33=3,  S34=0,  S57=0)  remained  unchanged  from  the 
in-air  experiment.  Based  on  the  500-m  range  and  the  in-air  experiments,  an  average  RTT 
of  approximately  35  s  was  expected. 

As  stated  before,  the  control  of  the  network  and  data  recording  were  supposed  to 
occur  remotely  using  a  server  ashore.  However,  technical  problems  with  both  the  Iridium 
modem  and  the  FreeWave  modem  left  local  recording  on  the  Racom  as  the  only  option. 
This  also  implied  that  the  network  could  not  be  adjusted  or  manipulated  once  it  was 
deployed,  which  limited  the  scope  of  the  experiment.  All  tests  were  therefore 
autonomously  conducted  with  the  above  settings. 
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D.  NETWORK  EVALUATION 


Two  trials  were  performed.  Trial  1  started  on  June  7  at  12:00LT  and  lasted  until 
June  8  07:30LT.  Trial  2  started  on  June  8  at  10:15LT  and  ended  at  16:30LT  that  same 
day.  Trial  2  included  a  controlled  run  by  a  small  boat  over  the  network.  Both  trials  started 
with  a  failure  from  unknown  causes,  which  activated  the  10-minute  out-of- action  period 
that  was  hard-coded  in  the  polling  algorithm.  It  was  observed  that  the  intended  10-minute 
silent  period  lasted  almost  two  hours.  We  hypothesize  that  interference  from  the  adjacent 
Seaweb  network  that  used  similar  modems  is  the  cause  for  this  unexpected  behavior.  The 
activity  of  these  modems  prevented  the  Seastar  modems  from  going  into  a  low-power 
state,  which  made  a  fresh  restart  impossible.  Once  the  activity  of  the  other  network  had 
ceased,  the  modems  entered  a  low-power  state  and  the  restart  occurred  as  intended. 


Figure  40  Summary  of  Seastar  prototype  performance  in  water  where  99.3%  of  the 

transmissions  were  successful. 


During  these  trials,  where  26  hours  of  network  operation  was  achieved,  a  total  of 
2031  successful  data  transmissions  were  made  by  the  peripheral  nodes  (see  Figure  40). 
Only  17  packets  were  initially  unsuccessful,  but  14  of  these  were  recovered  through 
SRQ.  An  additional  12  packets  were  dropped  because  the  poll  was  never  received.  The 
total  number  of  sub-packets  that  were  corrupted  was  53.  The  relevance  of  this  number 
can  be  found  when  considering  selective  retransmissions  through  SRQ  versus  full 
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retransmission  if  selectivity  had  not  been  used.  Instead  of  34816  bytes,  only  13568  bytes 
had  to  be  retransmitted,  which  is  a  reduction  of  almost  60%.  Only  three  packets  were 
found  out  of  sequence  and  they  were  all  retransmitted  successfully.  Including  the  network 
failures  at  startup,  a  total  of  three  full  network  self-recoveries  occurred  and  human 
intervention  in  the  network  was  never  required. 
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Figure  41  Summary  of  unsuccessful  transmissions  during  Trial  1  for  Addresses  3-7. 
Addresses  4,  5  and  6  experienced  the  most  interference. 
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Table  3  Summary  of  amount  and  description  of  unsuccessful  transmissions  during  Trial  1 

for  Addresses  3-7. 
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The  percentage  of  successfully  transmitted  packets  was  99.3%.  A  summary  of 
unsuccessful  transmissions  is  found  in  Figure  41  and  Figure  42  as  well  as  in  Table  3  and 
Table  4. 
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Figure  42  Summary  of  unsuccessful  transmissions  during  Trial  2  for  Addresses  3-7. 
The  number  of  unsuccessful  transmissions  was  too  few  to  be  of  statistical 
significance  but  the  trend  is  similar  to  Trial  1. 
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Table  4  Summary  of  amount  and  description  of  unsuccessful  transmissions  during  Trial  2 

for  Addresses  3-7. 

We  now  express  the  performance  of  the  Seastar  prototype  network  in  water  under 
the  above-described  conditions  in  terms  of  the  metrics  used  during  the  in-air  trials.  The 
average  latency  in  water,  based  on  the  data  in  Figure  43,  Figure  44  and  Table  5,  is  181  s 
compared  to  173  s  during  the  in-air  experiment.  Based  on  the  latency,  an  information 
throughput  of  408  bits/s  is  found  with  a  channel  utilization  of  0.51.  The  percentage  of 
dropped  packets  is  0.7%.  Only  a  small  portion  of  this  performance  degradation  can  be 
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Latency  (hh:mm:ss) 


attributed  to  the  longer  propagation  delays.  The  major  contribution  comes  from  the  fact 
that  unsuccessful  transmissions  and  retransmissions  caused  additional  delays. 


0:17:17 
0:14:24 
0:11:31 
0:08:38 
0:05:46 
0:02:53 
0:00:00 

14:30  18:30  22:30  02:30  06:30 

Time  (hh:mm) 

Figure  43  Latency  (vertical  axis)  measured  during  Trial  1.  The  peaks  are  due  to  either 

long  retransmissions  or  full  network  restart. 


-  address  3 
address  4 
address  5 
address  6 

-  address  7 


address  3 
address  4 
address  5 
address  6 
address  7 


Figure  44  Latency  (vertical  axis)  measured  during  Trial  2.  The  peaks  are  due  to  long 

retransmissions. 


Address 

Trial  1 
h:mm:ss 

Trial  2 
h:mm:ss 

3 

0:03:01 

0:03:00 

4 

0:03:01 

0:03:03 

5 

0:03:01 

0:03:03 

6 

0:03:01 

0:03:03 

7 

0:03:01 

0:03:00 

Table  5  Average  latency  for  specific  modems  during  both  trials. 
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From  a  qualitative  perspective,  we  would  like  to  associate  the  unsuccessful 
transmissions  with  certain  events  or  conditions.  The  sonobuoy  was  a  superb  tool  for 
identifying  interference  sources.  Four  unsuccessful  transmissions  occurred  due  to  the 
passage  of  a  small  boat,  another  four  were  caused  by  a  large  boat  and  four  transmissions 
were  corrupted  due  to  interference  from  the  nearby  Seaweb  network,  although  it  must  be 
mentioned  that  most  of  the  Seaweb  transmissions  did  not  interfere  with  Seastar 
operations.  The  cause  of  one  unsuccessful  transmission  could  not  be  determined.  All 
other  failures  occurred  at  time  intervals  during  which  the  sonobuoy  data  were  not  logged. 
Recordings  of  marine  mammals’  sonar  occurring  in  the  Seastar  band  did  not  indicate  any 
negative  interference.  An  example  of  an  SRQ  and  data  retransmission  due  to  the  passage 
of  a  small  boat  is  shown  in  Figure  45. 


Figure  45  Interference  due  to  passage  of  small  boat  causing  SRQ. 

Addresses  4,  5  and  6  required  the  most  retransmissions  and  the  majority  of  the 
dropped  packets  also  originated  from  these  addresses.  Knowing  the  causal  relation 
between  interference  from  both  shipping  and  the  Seaweb  modems,  it  is  not  a  surprise  to 
find  that  these  addresses  are  both  in  the  shipping  channel  and  in  close  proximity  to  the 
Seaweb  network.  On  the  other  hand,  no  reasons  can  be  found  for  the  exceptionally  good 
performance  of  Address  7,  since  it  was  closest  to  the  port  facilities  and  also  close  to  the 
Seaweb  network. 

We  conclude  this  chapter  and  the  experiment  sequence  with  the  following 

statements.  The  Seastar  prototype  has  been  successful  in  air  and  sea  trials.  The  star 
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topology  in  combination  with  a  polling  mechanism  has  proven  to  be  a  robust  strategy  that 
is  able  to  operate  autonomously  for  a  long  period.  It  needs  to  be  mentioned  that  we  were 
not  able  to  manipulate  network  parameters  and  that  the  results  were  obtained  under 
favorable  conditions.  Although  interference  from  shipping  and  Seaweb  was  observed,  we 
must  take  into  account  the  fact  that  Seastar  will  be  operating  in  a  higher  frequency  band. 
Since  the  anticipated  operational  environment  has  similarities  with  the  test  site,  further 
testing  with  future  high-frequency  modems  in  the  same  environment  is  strongly  advised. 
Although  the  network  was  reliable,  it  was  found  that  the  performance  was  limited.  The 
low  data  rates  in  combination  with  the  polling  (TDMA)  strategy  resulted  in  relatively 
high  latencies  and  a  low  information  throughput.  This  was  mainly  due  to  the  built-in 
random  delays  and  the  additional  10  s  delay  that  was  required  to  ensure  smooth 
cooperation  between  the  Seaweb  software  and  the  C  polling  algorithm.  Smart  integration 
of  both  algorithms  and  reducing  the  delays  in  the  hardware  could  greatly  increase  the 
network  performance.  Further  gains  may  be  realized  by  optimizing  the  network  strategy. 
Since  existing  hardware  does  not  allow  easy  implementation  of  strategies  such  as  P1D, 
PIE,  T2A  and  T3A,  this  will  be  done  in  the  next  chapter  though  simulation. 
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VI.  NETWORK  SIMULATION 


Having  demonstrated  a  Seastar  prototype  using  available  Seaweb  equipment,  we 
now  explore  various  networking  strategies  by  simulating  them  on  a  computer.  The 
simulation  allows  us  to  analyze,  evaluate,  and  optimize  various  candidate  strategies.  The 
output  metrics  of  the  simulations  are  presented  in  terms  of  channel  utilization, 
information  throughput,  latency,  and  dropped  packets.  The  results  of  the  experiments 
with  the  prototype  network  described  in  Chapter  V  provide  a  perfomance  benchmark. 

In  the  first  section  of  this  chapter  we  discuss  the  setup  of  the  simulation.  The  next 
section  shows  parametric  results  for  the  four  network  strategies  (P1D,  PIE,  T2B  and 
T3A)  described  in  Chapter  IV.  We  conclude  with  a  summary  of  pros  and  cons  for  these 
strategies.  This  then  forms  the  basis  of  case  studies  that  are  performed  in  Chapter  VII. 

A.  SIMULATION  SETUP 

Matlab  source  code  for  the  network  simulation  is  fully  shown  in  Appendix  B.  We 
designed  the  simulation  to  provide  the  possibility  of  analyzing  multiple  network  types 
simultaneously  under  similar  conditions.  Network  parameters,  to  be  described  soon,  can 
be  set  either  as  single  value  or  as  an  array  of  values.  The  simulation  is  time  and  event 
driven  and  depends  on  random  processes  to  trigger  certain  events,  such  as  failure  of  a 
transmission.  In  order  to  generate  statistically  relevant  results  where  the  effect  of  outliers 
is  insignificant,  each  simulation  is  repeated  a  large  number  of  times.  The  simulation 
duration  as  well  as  the  number  of  simulation  repeats  can  be  set  manually.  This  is  also  the 
case  for  the  SNR  threshold  levels  above  or  below  which  a  certain  event  will  occur.  Even 
though  these  levels  are  arbitrary,  the  events  that  are  triggered  behave  like  they  are  caused 
by  noise  so  that  the  effects  of  performance  degradation  on  the  communctaions  can  be 
studied.  Each  networking  strategy  is  evaluated  simultaneously  under  the  same  conditions 
and  each  strategy  is  initiated  with  the  same  set  of  input  parameters.  All  the  output  metrics 
are  averaged  over  time  and  over  the  number  of  simulation  repeats. 
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1.  Input  Parameters 


The  code  has  multiple  input  parameters  that  determine  the  performance  of  a 
specific  strategy.  Since  no  general  underwater  acoustic  LAN  network  data  are  available, 
the  data  obtained  from  our  experimental  Seastar  prototype,  such  as  delays  between 
transmissions,  length  of  headers  and  size  of  utility  packets,  served  in  many  cases  as 
“general”  input  data.  Often,  the  values  are  far  from  optimum  but  since  this  was  the  only 
way  of  calibrating  the  model  versus  a  real  system  and  since  all  strategies  experience  the 
same  effects  of  these  input  parameters,  a  comparison  between  the  four  candidate 
strategies  is  still  valid.  Since  many  parameters  have  relatively  similar  effects  on  each 
strategy,  a  selection  of  critical  parameters  had  to  be  made  to  emphasize  the  difference  in 
character  of  each  strategy.  The  following  critical  parameters  are  assessed  to  be  useful  and 
significant  for  expressing  the  fundamental  differences  in  network  strategy  and  the  effects 
of  varying  these  parameters  are  studied  in  the  next  section: 

•  Bit  rate  (high),  used  for  transmitting  data  packets. 

•  Bit  rate  (low),  used  for  transmitting  utility  packets  and  occasionally  for 
retransmissions. 

•  Number  of  peripheral  nodes. 

•  Packet  size. 

•  Sub-packet  size. 

•  Maximum  number  of  poll  or  token  retries. 

•  Maximum  number  of  SRQ  or  ACK  retries. 

•  Trigger  level. 

Each  parameter  is  assigned  a  default  value  for  the  simulation  as  shown  in  Table  6. 
Most  of  these  values  are  based  on  the  settings  of  the  Seastar  prototype  and  the  Teledyne 
Benthos  ATM-885  modems  as  used  during  the  in-water  experiments.  Although  we  expect 
performance  improvements  for  a  future  version  of  Seastar  compared  to  the  prototype, 
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such  as  higher  bit  rates  and  shorter  delays,  we  do  not  attempt  to  optimize  the  settings 
before  all  relevant  parameters  have  been  studied.  Such  optimization  will  be  attempted  for 


the  case  studies  in  Chapter  VII. 


PARAMETER 

REF 

UNITS 

DEFAULT 

PARAMETER 

REF 

UNITS 

DEFAULT 

Number  of  nodes 

n 

□ 

6 

packet  size 

DP 

[bytes] 

2048 

wake  up  time 

t\vu 

[s] 

0.4 

sub-packet  size 

Dsp 

[bytes] 

256 

acquisition  time 

tacq 

[s] 

0.28 

bit  rate  (data) 

Rbl 

[bits/s] 

800 

size  of  utility  packet 

dut 

[bytes] 

9 

bit  rate  (utility) 

R  h2 

[bits/s] 

140 

size  of  crc 

dCrc 

[bytes] 

2 

maximum  SRQ  retries 

Wlsrq 

[] 

3 

size  of  header 

dnw 

[bytes] 

14 

maximum  ACK  retries 

Mack 

[] 

3 

delay  poll-data 

tdl 

[s] 

1 

maximum  poll  retries 

tnPoii 

[] 

3 

delay  data-poll 

td2 

[s] 

2.9 

maximum  token  retries 

Mi-token 

[] 

3 

delay  manual 

td3 

[s] 

0 

trigger  level  0=nrin  l=max 

a 

[] 

0.05 

delay  data-SRQ 

td4 

[s] 

0.7 

simulation  period 

T 

[hrs] 

10 

time  out  period 

td5 

[s] 

7.5 

simulation  repeats 

A 

[] 

100 

Table  6  Input  parameters,  including  abbreviations  used  for  reference.  Most  of  the  default 
values  are  based  on  the  observed  performance  of  the  Seastar  prototype  during  the 

in-water  experiment. 


2.  Functions  and  Threshold  Levels 

The  simulation  code  uses  functions  to  perform  certain  calculations.  For  example, 
function  INI.m  is  used  to  set  network  parameters,  and  function  COLLECTDATA.m  is 
responsible  for  collecting  the  performance  data  of  the  networks  initialized  with  these 
parameters.  Each  network  strategy  is  implemented  as  described  in  Chapter  IV  by  a 
function  containing  multiple  loops  to  simulate  an  event-driven  network  operation  of  finite 
duration.  The  first  strategy  function  that  was  inserted  in  the  simulation,  however, 
represented  an  almost  exact  copy  of  the  Seastar  prototype  and  was  used  to  test  and 
calibrate  the  several  other  functions  so  that  the  output  values  matched  the  performance  of 
both  the  in-air  as  well  as  the  in- water  experiments. 

Each  strategy  function  calls  event  functions  to  perform  specific  actions  such  as 
polling,  data  transmission  or  SRQ.  Many  of  these  functions  contain  pseudo-random 
number  generators  that  are  summoned  each  time  the  function  is  called.  The  numbers  that 
are  generated  are  compared  to  threshold  levels  that  are  set  by  a  single  parameter  in  the 
INI.m  function,  known  as  the  threshold  a.  This  is  done  for  convenience,  and  to  ensure  a 
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consistent  relation  between  these  levels.  The  levels  that  are  set  by  a  are  called  LI,  L2,  L3, 
L23,  L4,  and  L5  and  determine  the  probability  of  events  to  occur,  as  can  be  seen  in 
Figure  46.  If  a  random  number  is  generated  between  LI  and  L2,  it  is  interpreted  as  an 
unsuccessful  poll  or  token  and  so  a  data  packet  is  not  transmitted  from  the  peripheral 
node.  Depending  on  the  strategy,  a  retransmission  will  follow  until  the  maximum  number 
of  retransmission  attempts  is  reached.  If  a  poll  or  token  is  successfully  received  by  a 
peripheral  node,  a  new  random  number  is  generated.  If  the  value  of  this  number  lies 
between  L2  and  L3,  the  data  packet  is  considered  corrupted  and  the  transmission  is 
unsuccessful.  The  level  L23  determines  if  the  failure  involves  the  header  of  the  packet  or 
one  or  more  sub-packets.  In  the  case  of  a  corrupted  header,  a  time-out  period  is  activated, 
followed  by  a  full  retransmission  if  the  network  strategy  permits.  In  the  case  of  one  or 
more  corrupted  sub-packets,  a  retransmission  follows,  again  depending  on  the  strategy, 
until  the  full  packet  is  successfully  received  or  until  the  maximum  number  of 
retransmissions  has  been  made.  The  success  of  a  retransmission  is  determined  by  L4.  The 
level  L5  just  sets  the  lower  level  to  zero. 


These  sequences  of  events,  including  retransmissions  and  dropped  packets,  then 
have  an  impact  on  the  RTT  and/or  the  amount  of  data  transmitted.  Flags  can  be  set  by 
functions  to  memorize  actions  that  require  follow  up  during  the  subsequent  cycle,  such  as 
retransmissions  in  case  of  T3A  or  the  occurrence  of  a  packet-out-of-sequence  situation. 


LI 

L2 

L23 

L3 


L5 


L4 


LI  =1 
L2=  1  -a 
L3=1-2 a 
L23=L4=a 
L5=0 


Figure  46  Graphical  representation  (not  to  scale)  of  the  organization  of  levels  as  set  by 
threshold  a.  The  levels  determine  the  probability  of  a  certain  event  to  happen. 
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Because  of  the  random  occurrences  of  events  and  the  large  variations  in  output 
that  this  process  generates,  our  performance  analysis  depends  on  a  Monte  Carlo-type 
method  to  find  statistically  significant  output  values.  Although  this  method,  as  introduced 
in  [42],  describes  a  statistical  approach  to  study  differential  equations  that  occur  in 
various  branches  of  the  natural  sciences  and  since  we  do  not  provide  these  differential 
equations,  the  method  is  applicable  to  our  case  since  it  finds  the  most  likely  outcome  of  a 
multi -parameter  process.  By  having  the  simulation  produce  a  multitude  of  randomly 
generated  possible  outcomes  and  average  them,  we  find  a  most  likely  behavior  of  a 
specific  strategy  under  certain  conditions.  The  Monte  Carlo  method  requires  a  significant 
number  of  outcomes,  hence  the  multiple  repetitions  of  a  network  simulation  over  a 
significantly  long  time.  As  Table  6  shows,  all  simulations  were  conducted  for  a  simulated 
time  of  10  hours  and  averaged  over  100  realizations.  To  illustrate  this  numerically,  we 
consider  an  average  performance  outcome  (e.g.,  latency=160  s)  for  the  four  strategies 
using  the  default  settings  of  Table  6  in  a  noise-free  environment  (a=0).  During  these  100 
realizations  of  10-hour  network  operations,  approximately  135,000  transmissions 
occurred  and  were  used  in  calculations  to  estimate  a  most  probable  outcome.  This  count 
varies,  of  course,  with  changing  parameters  (e.g.,  longer  packets  reduce  the  amount  of 
transmissions,  higher  bit  rates  increase  this  amount)  but  it  shows  that  the  number  of 
events  is  sufficiently  large  for  applying  a  Monte  Carlo-like  approach.  We  will  now 
discuss  how  the  output  parameters  are  obtained. 

3.  Output  Metrics 

Channel  utilization,  information  throughput,  latency,  and  dropped  packets  are 
measured  as  follows.  Each  address  receives  a  poll  or  token  utility  packet  and  transmits  its 
data.  The  total  time  Txmit ,  including  overhead  and  retransmissions  required  for  performing 
this  round-trip  transmission  and  the  total  amount  of  information  DATA  including 
retransmitted  packets,  is  stored  for  each  address.  The  simulation  also  keeps  track  of  the 
number  of  dropped  and  successful  packets.  These  variables  are  used  to  update  the  total 
transmission  time  and  total  transmitted  information  for  each  node  ( Tmodem  and  Dmodem, 

respectively),  for  each  cycle  ( Tryde  and  D  cle ,  respectively)  and  for  the  total  simulation 
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duration  ( Ttotal  and  Dtotal,  respectively).  The  latency  is  calculated  by  summing  T  cJe  for 
each  cycle.  The  information  throughput  over  the  period  T  is  calculated  by  dividing  Dtotal 
by  Trolal .  The  channel  utilization  over  the  period  T  is  obtained  by  taking  the  ratio  of  the 
information  throughput  (Dtotal/Ttotal)  and  the  bit  rate  Rhi .  The  percentage  of  dropped 

packets  during  the  period  T  is  simply  the  ratio  of  the  dropped  packets  over  the  total 
number  of  transmitted  packets.  Finally,  all  the  calculated  values  are  averaged  over  the 
total  number  of  realizations  A,  resulting  in  a  set  of  statistically  significant  output 
parameters  for  channel  utilization,  information  throughput,  latency,  and  dropped  packets. 

4.  Limitations 

The  simulation  has  certain  limitations  in  representing  the  performance  of  the 
candidate  network  strategies.  First  of  all,  the  strategies  themselves  are  ideal  models  of 
possible  future  implementations.  Packets  ending  up  out  of  sequence,  for  example,  can 
easily  be  avoided  in  this  simulation  since  corrupted  packets  will  either  be  retransmitted  or 
dropped.  In  order  to  analyze  actions  responding  to  the  detection  of  a  packet  that  is  out  of 
sequence,  a  packet  that  is  dropped  after  an  unsuccessful  poll  or  token  is  artificially  placed 
out  of  sequence.  The  network  now  has  to  solve  this  situation  during  its  next  cycle.  In  a 
real  situation  this  packet  would  just  be  dropped  or  retransmitted  depending  on  the 
network  design. 

Although  the  simulation  has  been  calibrated  using  experimental  data  in  terms  of 
performance  metrics,  the  threshold  a  is  just  a  value  between  0  and  1  and  the  levels  that 
depend  on  a  do  not  represent  true  noise  levels  or  SNR  values.  The  simulation  can 
therefore  not  be  used  to  analyze  the  performance  in  a  specific  geographic  region  or  to 
determine  network  settings  prior  to  operational  deployment.  This  would  require  a  more 
sophisticated  model  and  additional  environmental  input  parameters. 

Another  important  limitation  is  that  the  propagation  delays  are  set  for  a  fixed 
inter-nodal  range  of  500  m  and  therefore  do  not  provide  the  flexibility  to  analyze  network 
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performance  when  repositioning  the  nodes.  Nor  does  it  support  analysis  of  mobile  nodes. 
Generality  of  the  simulation  was  not  possible  due  to  time  constraints,  but  should  be 
relatively  easy  to  implement. 

Overall,  the  simulation  is  found  useful  for  providing  performance  comparisons  of 
the  four  network  strategies  of  interest.  The  code  is  flexible  enough  to  analyze  other  forms 
of  networks  strategiesof  so  required.  We  now  proceed  by  using  the  code  for  a  parametric 
analysis  of  the  strategies  P1D,  PIE,  T2B,  and  T3A  in  terms  of  channel  utilization, 
information  throughput,  latency,  and  dropped  packets. 

B.  PARAMETRIC  ANALYSIS 

Throughout  this  section,  we  vary  one  relevant  parameter  at  a  time,  while  keeping 
all  others  default  as  given  by  Table  6.  In  some  instances  it  is  necessary  to  study  the 
effects  of  a  certain  parameter  in  more  depth,  which  may  require  adjusting  other 
parameters.  Deviations  from  the  default  settings  will  be  clearly  announced.  Setting 
parameters  to  values  that  have  earlier  in  this  thesis  shown  not  yet  realistic  is  justified  in 
anticipation  of  future  technical  improvements.  Another  justification  is  that  trends  become 
more  clear  and  differences  more  profound  when  analyzing  over  a  larger  range. 

1.  Bit  Rate 

Recall  that  the  asymmetric  concept  involves  two  bit  rates,  a  high  bit  rate  for  data 
transfer  Rbl  and  a  low  bit  rate  for  utility  packets  Rb2 .  The  simulation  for  analysis  of  Rh]  is 
conducted  for  Rbl  =  [500,  1000,  4000,  10000,  20000,  40000]  bits/s.  Increasing  Rbl  over 
this  range,  as  is  done  in  Figure  47,  which  shows  the  effect  on  utilization,  information 
throughput,  latency  and  dropped  packets,  does  not  result  in  a  linear  improvement  of  the 
information  throughput  and  results  in  very  low  channel  utilization  for  all  network 
strategies.  At  large  values  for  Rbl,  the  network  performance  is  limited  by  the  amount  of 

overhead,  consisting  of  (propagation)  delays  and  utility  packets.  This  also  sets  a  lower 
limit  for  the  latency. 
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To  study  the  influence  of  communications  overhead  in  more  depth  we  consider 
the  following  input  parameters:  twu  =  0.2  s,  tacq  =0.14  s,  tdl  =0.7  s,  td2  =0.7  s,  td5  =3.5 

s  and  Rh-,  =  4000  bits/s.  With  these  improved  values,  a  better  information  throughput  is 


observed  (see  Figure  48  for  P1D)  but  overhead  remains  a  constraint. 


Bit  rate  -  data  (bits/s) 


Bit  rate  -  data  (bits/s) 


xIO4 


Figure  47  Increasing  the  bit  rate  Rhl  (horizontal  axis),  expressed  in  terms  of  utilization, 

throughput,  latency  and  dropped  packets,  has  a  limited  effect  on  improving  the 
network  performance  because  of  the  increasing  relative  influence  of  overhead.  All 
other  input  parameters  other  than  Rbl  are  set  to  default  values. 


It  may  be  obvious  that  P1D  proved  to  be  the  most  reliable  network  type  under 
these  conditions  because  of  its  SRQ  ability.  The  number  of  dropped  packets  in  the 
simulation  is  independent  of  the  bit  rate.  Based  on  experiments  described  in  Chapter  IV  it 
should  be  taken  into  account  that  higher  bit  rates,  when  caused  by  a  reduction  of 
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redundant  bits,  generally  do  result  in  an  increase  in  transmission  failures.  T2B 
demonstrates  the  best  information  throughput  and  lowest  latency  but  at  the  cost  of 
dropping  5-6%  of  the  packets.  Overall,  all  network  strategies  were  affected  to  a  similar 
extent  by  an  increased  Rbl  and  performance  for  all  strategies  was  limited  by  the 
correspondingly  increased  influence  of  overhead. 


Figure  48  Reducing  communications  overhead,  here  shown  for  P1D,  improves  the 
information  throughput  of  the  network  but  still  constrains  perfromance  at  high 
Rbi.  Input  parameters  for  this  study  compare  the  default  values  with  optimized 

values. 

Increasing  the  utility  packet  bit  rate  by  setting  Rb2=[50  100  200  400  800] 

improves  the  information  throughput  and  reduces  latency  for  all  strategies.  Strategy  T3A 
especially  benefits  from  a  reduced  overhead  because  time  consumed  by  the  additional 
hop  is  reduced.  Notice  that  in  Figure  49,  unlike  with  Rbl ,  the  channel  utilization  increases 

with  increasing  Rb2 .  Although  increasing  Rhl  improves  the  network  performance,  we 
anticipate  a  relatively  higher  Rbl  in  future  Seastar  implementations  and  so  it  must  be 

recognized  that  increasing  the  bit  rate  has  its  physical  limits  due  to  the  inevitable 
overhead  caused  by  delays  and  network  headers. 
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Figure  49  Increasing  Rb2  (horizontal  axis)  improves  network  performance  and 
efficiency  in  terms  of  information  throughput  and  channel  utilization,  and 
simultaneously  reduces  latency.  All  input  parameters  other  than  Rbl  are  set  to 

default  values. 


2.  Packet  and  Sub-packet  Size 

In  general,  larger  information  packets  Dp  result  in  good  channel  utilization  and 
information  throughput  since  the  percentage  of  overhead  is  reduced.  For  an  analysis 
where  Dp  =[256,  512,  2048,  8192,  16348,  32768]  bytes,  it  can  be  observed  (see  Figure 

50)  that  the  advantage  in  terms  of  information  throughput  and  channel  utilization  of 
network  type  T2B  is  slightly  reduced  at  packet  size  larger  than  7  kilobytes  (kbytes), 
although  it  still  shows  the  lowest  latency.  P1D  and  T3A  have  about  the  same  improved 
information  throughput  at  larger  packet  sizes.  Increasing  packet  size  seems  favorable  but 
it  unfortunately  also  results  in  a  longer  latency  (see  Figure  50). 
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Figure  50  Increasing  the  size  of  packets  D  (horizontal  axis)  improves  the  information 
throughput  and  the  channel  utilization  but  has  a  negative  effect  on  the  latency.  All 
input  parameters  other  than  D  are  set  to  default  values. 


The  latency,  however,  can  easily  be  reduced  by  increasing  Rhl .  Figure  5 1  shows 
the  effect  of  packet  size  with  increased  Rhl  (10000  bits/s)  and  Rhl  (4000  bits/s)  and 
setting  twu  =0.2  s,  tacq=  0.14  s,  trU  =  0.7  s,  td2  =  0.7  s,  td5=  3.5  s  for  P1D.  Not  only 

does  this  reduce  latency,  it  also  further  improves  the  network  performance  in  terms  of 
information  throughput.  Increasing  the  packet  size  therefore  needs  to  be  considered  in 
conjunction  with  other  parameters  but  again,  the  negative  effects  of  overhead  are  a 
limiting  factor  on  information  throughput. 
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Figure  5 1  Simultaneously  increasing  packet  size  (horizontal  axis)  and  bit  rate  (dashed 
line)  improves  both  the  information  throughput  (left)  as  well  as  the  latency  (right), 

as  is  shown  here  for  P1D. 


The  percentage  of  dropped  packets  is  unaffected  by  the  packet  size  but  a  potential 
risk  for  longer  latencies  develops  when  noise  levels  increase  and  full  packets  need  to  be 
retransmitted,  as  is  shown  in  Figure  52,  where  a  =  0.2  and  the  other  parameters  are  set  to 
default  values. 
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Figure  52  Increasing  size  of  packets  in  a  “noisier”  environment  ( a  =  0.2 ).  Full  packet 
retransmissions  cause  long  latencies  for  SRQ-able  strategies.  Non-SRQ  strategies, 
on  the  other  hand,  drop  an  unacceptably  large  percentage  of  packets.  All  input 
parameters  other  than  Dp  and  a,  are  set  to  default  values. 


We  now  turn  our  attention  to  the  effect  that  the  length  of  sub-packets  has  on  the 
network  performance  and  set  Dsp  =  [64,  128,  256,  512,  1024,  2048]  bytes,  with 

D  =2048  bytes.  It  should  be  mentioned  that  the  Dp  parameter  does  not  affect  PIE  and 
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T2B  since  these  two  strategies  lack  the  provision  to  retransmit  data  packets.  Varying  the 
sub-packet  size  shows  us  some  interesting  results  for  network  types  P1D  and  T3A  as 
shown  in  Figure  53. 


Figure  53  Reducing  the  size  of  sub-packets  D  p  (horizontal  axis)  shows  an  optimum 
value  near  Dsp  ~  500  bytes  under  default  conditions  ( a  =  0.05 )  for  P1D  and  T3A. 
Since  PIE  and  T2B  do  not  use  SRQ,  changing  Dsp  does  not  have  any  effect.  All 
input  parameters  other  than  D  ,  are  set  to  default  values. 


Both  show  a  maximum  value  for  channel  utilization  and  information  throughput 
and  a  minimum  value  for  latency,  resulting  in  an  optimum  sub-packet  size  at  Dsp  ~  500 

bytes.  At  values  of  D  below  the  optimum,  the  network  performance  is  degraded  due  to 
the  additional  CRC  overhead  associated  with  a  larger  number  of  sub-packets.  At  values 
of  Dsp  above  the  optimum,  the  network  performance  is  degraded  because  of  the  lengthy 
retransmissions  that  need  to  be  made.  The  position  of  the  optimum  is  determined  by  the 
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amount  of  noise  that  is  introduced.  As  an  example,  we  set  a  =  0.2  in  Figure  54  to  show 
that  increased  noise  levels  cause  the  optimum  to  shift  to  the  smaller  sub-packet  sizes  as 
may  be  expected. 


Figure  54  The  position  of  the  optimum  size  of  sub-packets  Dp  is  determined  by  the 

amount  of  retransmissions  that  is  required.  Increasing  the  “noise”  by  setting 
a  =  0.2  causes  the  optimal  Dp  to  shift  to  smaller  values,  in  this  case 

Dsp  ~  100 bytes.  All  input  parameters  other  than  Dsp  and  a,  are  set  to  default 

values. 


In  general,  large  sub-packets  will  cause  longer  delays  in  a  noisy  environment 
since  many  retransmissions  are  anticipated.  Breaking  up  the  packet  into  many  small  sub¬ 
packets  reduces  the  latency.  In  relatively  noise-free  environments,  however,  the  negative 
influence  of  CRC  overhead  due  to  the  larger  number  of  sub-packets  contributes  to  a 
decreased  information  throughput  as  well  as  longer  latency. 

Increasing  bit  rates  and  reducing  delays  (Rbl  =10000  bits/s,  Rh2  =  4000  bits/s, 
twu=  0.2  s,  t  =  0.14  s,  tdi  =  0.7  s,  td2  =  0.7  s,  td5=  3.5  sand  a  =  0.2 )  removes  the 
presence  of  an  optimum  D  and  favors  T2B  and  T3A  over  P1D  and  PIE  as  is  shown  in 
Figure  55. 
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Figure  55  Operating  at  higher  bit  rates  with  reduced  delays  as  described  above  reduces 
the  appearance  of  an  optimum  value  for  D  p  and  favors  T2B  and  T3A  over  P1D 

and  PIE. 

In  general,  small  sub-packets  are  preferred  in  noisy  environments  and  T3A  is  the 
preferred  strategy  under  these  conditions. 


3.  Number  of  Peripheral  Nodes 

Recall  that  our  simulation  uses  fixed  propagation  delays  whereas  a  change  in  the 
number  of  nodes  actually  requires  adjusting  these  ranges.  For  example,  from  Table  2  we 
find  a  range  reduction  of  146  m  for  n  =  4  which  agrees  with  0.097  s  for  a  sound  speed  of 
1500  m/s.  Even  when  considering  a  round  trip  transmission  of  10  s,  the  difference  in 
transmission  time  is  less  than  1%,  so  ignoring  the  range  adjustment  has  a  negligible  effect 
on  the  calculations.  As  expected,  the  number  of  nodes  only  has  an  effect  on  latency. 
Figure  56  shows  that,  except  for  T3A,  there  is  no  impact  on  channel  utilization, 
information  throughput  or  dropped  packets  when  analyzing  for  n=[ 4,  6,  8,  10,  12] 
peripheral  nodes. 
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Using  default  settings,  T3A  shows  a  degraded  performance  in  terms  of  utilization 
and  information  throughput  with  increasing  number  of  modems. 


Figure  56  For  P1D,  PIE  and  T2B,  the  number  of  peripheral  nodes  n  (horizontal  axis) 
only  affects  the  latency  of  the  network.  The  information  throughput  of  T3  A 
decreases  with  increasing  n  because  of  the  increasing  length  of  the  token.  All 
input  parameters  other  than  n,  are  set  to  default  values. 


A  surprising  result  arises  when  the  low  bit  rate  Rbl ,  which  determines  the 
transmission  speed  of  utility  packets  such  as  the  token,  is  increased  from  the  initial  value 
of  140  bits/s  to  higher  speeds.  For  this  analysis  we  set  Rbl  =10  kbits/s.  Figure  57  shows 
the  appearance  of  a  maximum  value  for  information  throughput,  shifting  to  the  right 
(larger  number  of  modems)  for  increasing  Rbl  and  finally  resulting  in  the  reverse  effect, 

namely  an  improved  performance  for  increasing  number  of  nodes.  Recall  that  T3A 
requires  a  hop  through  the  central  node  to  update  the  token  and  that  each  additional  node 
adds  bytes  to  the  token.  The  explanation  for  the  phenomenon  observed  in  Figure  57  can 
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be  found  in  the  fact  that  at  low  Rbl  (e.g.,  140  bits/s)  the  performance  of  T3A  is 
dominated  by  the  overhead  due  to  the  increasing  length  of  the  token.  At  high  Rb2 ,  the 

reduced  impact  of  the  “central  node  hop”  through  the  addition  of  more  peripheral  nodes 
dominates  the  relative  loss  of  an  increased  token  length.  Careful  design  of  the  token  as 
well  as  applied  bit  rates  for  network  type  T3A  is  therefore  paramount. 


Figure  57  Increasing  the  number  of  peripheral  nodes  (horizontal  axis)  at  Rhl  =  140  bits/s 
(  Ria  =  10  kbits/s)  results  in  a  decreased  information  throughput  for  T3A. 

Increasing  Rb2  as  shown  to  Rhl  =  [300,  600,  1000,  2000],  reverses  this  effect. 

In  general  it  can  be  stated  that  more  nodes  mean  a  higher  sensor/modem  density  at 
the  cost  of  increased  latency. 

4.  Number  of  Retransmissions 

The  maximum  number  of  retransmissions  m  determines  how  many  times  a 
specific  packet  is  allowed  to  be  retransmitted  before  it  is  dropped.  For  this  analysis  we  set 
m  =  msrq  =  mack  =  mPou  =  m,oken  =  [ 1 ,  2,  3,  4,  5,  6,  8].  The  effect  of  increasing  this 

parameter  clearly  depends  on  the  amount  of  noise  imposed  upon  the  network  and  in  order 
to  observe  a  sufficient  number  of  retransmissions  and  emphasize  the  differences,  we  set 
a  =  0.2.  Since  PIE  and  T2B  do  not  allow  for  retransmitting  corrupted  data  or  utility 
packets,  the  maximum  number  of  retransmissions  does  not  affect  these  strategies.  The 
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outcome  of  this  analysis  (see  Figure  61),  should  be  interpreted  with  some  reserve.  Recall 
that,  for  simulation  purposes,  a  packet  is  put  out  of  sequence  once  the  maximum  number 
of  poll  or  token  retransmissions  has  been  achieved.  Usually,  an  event  like  this  does  not 
happen  very  often  but  since  the  simulation  for  this  specific  parameter  includes  extremities 
(e.g.,  a  =  0.2  in  combination  with  small  values  for  m),  packets  do  end  up  out  of  sequence 
frequently.  When  that  happens,  full  retransmission  occurs  at  a  bit  rate  of  Rb2  instead  of 

Ria  ,  which  has  a  dramatic  effect  on  the  network  performance  of  P1D  and  T3A.  Although 

the  results  for  low  m  may  underestimate  the  performance,  the  analysis  is  useful  because  it 
shows  the  advantage  of  being  able  to  retransmit  corrupted  packets.  At  the  same  time  it 
also  shows  that  the  performance  levels  off  at  n  >  5 . 


Figure  58  Effect  of  number  of  retransmission  retries  m  (horizontal  axis)  for  “very  noisy” 
conditions  (a  =  0.2 ).  The  ability  to  retransmit  packets  ensures  a  relatively  good 
information  throughput  at  a  low  dropped  packet  percentage,  at  the  cost  of 
increased  latency.  All  input  parameters  other  than  m  and  a,  are  set  to  default 

values. 
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In  general,  network  strategies  that  are  capable  of  retransmitting  packets  ensure 
reliable  data  transfer  in  terms  of  dropped  packets  and  information  throughput.  For 
“noisy”  conditions,  the  cost  of  longer  latency  for  P1D  and  T3A  is  acceptable,  certainly 
when  considering  the  large  number  of  dropped  packets  that  arise  from  PIE  and  T2B. 

5.  Noise 


The  introduction  of  the  effects  of  “noise,”  represented  qualitatively  by  the 
threshold  a,  has,  in  some  cases,  already  been  discussed  in  combination  with  previous 
parameters.  In  the  figures,  a  is  expressed  as  a  percentage  and  can  be  interpreted  as  a 
qualitative  variable  that  determines  the  success  rate  of  a  transmission.  The  threshold  does 
not  directly  refer  to  SNR,  SL,  NL  or  TL,  but  can  be  used  as  a  “knob”  to  set  system  or 
channel  degradation.  As  an  example,  a  =  0.1  means  that  10%  of  packets  of  any  type  are 
initially  unsuccessful,  and  the  experienced  a  during  the  in-water  experiments  was  0.01. 


Figure  59  The  effect  of  “noise”  on  the  output  metrics  is  set  by  the  threshold  (horizontal 
axis).  All  input  parameters  other  than  a,  are  set  to  default  values. 
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For  a  =  [ 0,  0.01,  0.05,  0.1,  0.15,  0.2]  the  simulation  puts  P1D  and  T3A  in  favor 
over  PIE  and  T2B  in  terms  of  information  throughput  when  a>  0.1.  This  value  for  a 
shifts  up  when  setting  Rbl  =  10000  bits/s,  Rb2  =  4000  bits/s,  twu  =  0.2  s,  tacq=  0.14  s, 

tdl  =  0.7  s,  td2  =  0.7  s,  td5  =3.5  s,  as  can  be  seen  in  Figure  60  but  the  trend  remains  the 
same. 


Figure  60  Parametric  analysis  for  a  or  packet  error  rate  (horizontal  axis)  at  higher  bit 
rates  and  reduced  delays  as  described  above.  The  strategies  shift  relative  from 
each  other  but  still  show  a  similar  trend  as  with  the  default  settings. 

The  best  metric  to  analyze  the  performance  of  network  strategies  under  the 
influence  of  noise  is,  however,  not  always  information  throughput.  In  case  of  a  >  0.05 , 
the  dominant  factor  for  choosing  a  strategy  will  almost  certainly  be  the  amount  of 
dropped  packets,  which  is  unacceptably  high  for  PIE  and  T2B.  Even  when  the  maximum 
number  of  allowed  retransmissions  for  P1D  and  T3A  is  reduced  to  m  =  1  (Figure  61), 
PIE  and  T2B  show  a  relatively  very  poor  performance  in  terms  of  dropped  packets. 
Referring  again  to  the  in-water  experiments  that  were  done  with  the  prototype,  where 
a  =  0.01,  we  state  that  T2B  would  perform  well  enough  under  these  low-noise 
conditions,  but  over  the  full  range,  when  reliable  message  delivery  is  required,  T3A 
performs  best,  followed  by  P1D. 
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Figure  61  Even  though  P1D  and  T3A  are  only  allowed  one  retransmissions  ( m  =  1 ),  they 
remain  the  preferred  strategy  under  “noisy”  conditions  (horizontal  axis)  when 
considering  the  percentage  of  dropped  packets. 


C.  TRADEOFFS 

It  should  be  clear  by  now  that  the  optimum  strategy  does  not  exist.  Defining  an 
optimum  strategy  depends  on  operational  requiremens,  such  as  required  reliability, 
latency  and  throughput.  We  have  also  seen  that  channel  noise  plays  an  important  role  in 
determining  the  strategy.  In  order  for  the  reader  to  comprehend  the  results  of  the 
parametric  analysis  in  a  nutshell  we  try  to  summarize  the  generally  observed  trends  in 
two  ways. 

First,  we  summarize  the  results  of  the  parametric  analysis  graphically  (see  Figure 
62),  and  indicate  the  effect  that  increasing  or  reducing  the  value  of  a  certain  parameter 
has  on  channel  utilization,  information  throughput,  latency  and  dropped  packets.  As  an 
example,  increasing  the  data  bit  rate  RIA  generally  has  a  negative  (red)  effect  on  channel 
utilization  (upper  left  field)  but  a  positive  (green)  effect  on  information  throughput.  It 
must  be  emphasized  that  Figure  62  shows  general  effects  and  that  a  specific  strategy  or 
changing  certain  parameters  may  influence  or  change  to  what  extent  a  certain  effect  is 
observable.  Also  note  that  an  additional  parameter  td  is  expressed  explicitly  to  clarify 

that  the  parametric  analysis  includes  effects  of  reducing  delays  as  part  of  the  analysis 
when  overhead  is  reduced. 
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Figure  62  Summary  of  parametric  analysis.  Columns  indicate  increasing  (arrow  up)  or 
decreasing  (arrow  down)  parameter  values  and  the  effect  of  this  on  the  metrics 

used  (rows). 


Noise  is  the  only  parameter  that  generally  cannot  be  influenced  and  that  has  a 
profound  effect  on  the  preferred  network  strategy.  To  express  the  influence  of  noise  on 
network  performance  more  specifically,  we  dedicate  a  second  summary  to  the 
relationship  between  the  performance  of  a  specific  network  strategy  and  the  various 
parameters,  under  low-noise  (a  =  1%)  and  high-noise  (Of  =  20%)  conditions, 
respectively. 
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Figure  63  Performance  of  network  strategies  for  a  =  0.01  (upper  table)  and  0.2  (lower 
table),  respectively,  for  designated  parameters.  T2B  excels  in  very  low-noise 
environments.  In  noisy  environments,  P1D  performs  best  in  terms  of  reliability 
whereas  T3A  performs  best  in  terms  of  information  throughput  and  latency. 
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Figure  63  reveals  a  couple  of  interesting  trends,  although  one  should  interpret  the 
figure  with  some  reserve  since  the  performances  of  some  strategies  are  sometimes 
comparable  (e.g.,  see  Figure  50).  Nevertheless,  the  following  hard  conclusions  can  be 
made. 

Strategies  PIE  and  T2B  perform  poorly  under  noisy  (e.g.,  a  >0.02)  conditions 
because  of  the  inability  to  retransmit  packets.  Strategy  PIE  also  shows  a  relatively  poor 
performance  even  under  good  conditions.  In  the  case  of  both  a  =  0.01  and  a  -  0.2 ,  P1D 
and  T3A  show  almost  always  a  comparable  performance,  which  is  good  because  it  allows 
the  choice  between  two  different  strategies  depending  on  requirements.  Strategy  T3A 
performs  slightly  better  in  terms  of  channel  utilization,  information  throughput  and 
latency  whereas  P1D  scores  better  in  terms  of  reliability  since  it  almost  always  maintains 
a  zero  dropped  packet  rate. 

Considering  all  possible  environmental  conditions  we  therefore  conclude  the 
parametric  analysis  by  stating  that  T2B  shows  superior  performance  in  terms  of 
utilization,  information  throughput  and  latency  but  is  only  useful  if  reliability  in  terms  of 
dropped  packets  does  not  have  the  highest  priority.  Strategy  PIE  shows  the  poorest 
performance  but  may  be  preferred  because  it  is  independent  of  relative  positioning 
between  neighboring  nodes.  If  reliability  of  data  transfer  is  desirable  (which  it  almost 
always  is)  then  P1D  and  T3A  both  perform  well.  T3A  is  the  fastest  and  indicates  the 
highest  throughput  but  is  less  flexible  in  terms  of  geometry  because  it  depends  on 
communication  between  neighboring  nodes.  Strategy  P1D  maintains  the  highest 
reliability  because  of  its  ability  to  retransmit  multiple  times  but  at  the  cost  of  longer 
latencies.  We  must  not  forget  that  hybrid  or  other  forms  of  the  above  strategies  are 
possible. 
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VII.  CASE  STUDIES 


In  this  chapter  we  use  the  simulation  to  consider  possible  future  Seastar 
applications.  The  ideas  for  the  case  studies  are  generally  inspired  by  the  Underwater 
Persistent  Surveillance  (UPS)  experiment  that  was  conducted  as  part  of  the  Monterey  Bay 
2006  field  experiments  [43]. 

A.  ELECTROMAGNETIC  RECONNAISSANCE 

The  first  case  study  involves  a  fixed  underwater  reconnaissance  system, 
consisting  of  magnetometers  to  detect  magnetic  anomalies  associated  with  the  passage  of 
ships  or  submarines  (e.g.,  see  Figure  64).  Upon  detection,  the  magnetic  signature  of  the 
target  is  determined  and  a  rough  tracking  is  obtained.  The  system  is  based  on  a  Seaweb 
wide-area  network  where  each  Seaweb  node  serves  as  the  central  node  for  a  Seastar  LAN 
and  each  peripheral  node  includes  a  magnetic  anomaly  detector.  We  examine  the  network 
performance  of  a  single  Seastar  LAN. 


1  km 

◄ - ► 


Figure  64  Schematic  representation  of  a  surveillance  network  with,  in  this  case,  four 
peripheral  nodes  with  magnetic  sensors  having  a  300-m  detection  range. 
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The  operational  requirements  are  as  follows.  The  Seastar  LAN  should  cover  1 
km  and  within  this  area,  a  target  on  a  fixed  heading  should  pass  within  detection  range 
of  at  least  two  sensors  to  allow  rough  tracking.  The  magnetic  sensor  has  a  maximum 
detection  range  of  300  m.  The  target  has  a  maximum  target  speed  of  30  knots 
(~  55  km/hr).  Near-real-time  updates  consisting  of  fused  data  from  the  central  node  is 
required  with  a  latency  of  less  than  one  minute.  A  raw  data  packet  containing  signature 
data  that  has  been  preprocessed  by  the  magnetic  sensor  is  assumed  to  have  a  size  of  2 
kbytes.  Delivery  of  packets  needs  to  be  ensured,  keeping  in  mind  that  the  latency  should 
not  exceed  60  s.  The  network  should  operate  under  noisy  channel  conditions  and 
disruption  because  the  passage  of  loud  targets  should  be  expected. 

The  system  default  settings  are  optimized  and  are  displayed  in  Table  7.  Since  the 
percentage  of  dropped  packets  needs  to  be  minimized  and  the  network  is  required  to 
operate  in  noisy  conditions,  PIE  and  T2B  are  found  not  suitable  and  are  not  analyzed. 


PARAMETER 

REF 

UNITS 

DEFAULT 

PARAMETER 

REF 

UNITS 

DEFAULT 

Number  of  modems 

Tl 

□ 

var 

packet  size 

DP 

[bytes] 

2000 

wake  up  time 

t\vu 

[s] 

0.1 

sub-packet  size 

Dsp 

[bytes] 

var 

acquistition  time 

tacq 

[s] 

0.1 

bit  rate  (data) 

Rbl 

[bits/s] 

var 

size  of  utility  packet 

dut 

[bytes] 

8 

bit  rate  (utility) 

R  i>2 

[bits/s] 

var 

size  of  crc 

dCrc 

[bytes] 

2 

maximum  SRQ  retries 

Wlsrq 

[] 

3 

size  of  header 

dnw 

[bytes] 

12 

maximum  ACK  retries 

ffl-ack 

[] 

3 

delay  poll-data 

tdl 

[s] 

0.4 

maximum  poll  retries 

mpoii 

[] 

3 

delay  data-poll 

td2 

[s] 

0.4 

maximum  token  retries 

Mi-token 

[] 

3 

delay  manual 

td3 

[s] 

0 

trigger  level  0=nrin  l=max 

a 

[] 

var 

delay  data-SRQ 

td4 

[s] 

0.4 

simulation  period 

T 

[hrs] 

10 

time  out  period 

td5 

[S] 

3 

simulation  repeats 

A 

[] 

100 

Table  7  Settings  for  reconnaissance  case  study.  The  value  “var”  refers  to  a  variable  that  is 

an  outcome  of  the  simulation. 

Our  analysis  first  focuses  on  the  required  bit  rate  Rbl  (see  Figure  66).  For 
/?m=[2000,  4000,  6000,  8000,  10000]  bits/s,  Rhl  =  2000  bits/s,  n  =  4,  Dsp  =  256 bits, 
and  a  =  0.01 ,  we  find  that  Rhl  >  2000  bits/s  keeps  the  latency  well  below  the  desired  60 


100 


s.  Both  P1D  and  T3A  do  not  differ  much  from  each  other  in  performance  and  the  small 
percentage  of  dropped  packets  (e.g.,  -0.01%)  under  these  conditions  for  T3A  is 
acceptable. 


Figure  65  Effects  of  bit  rate  Rhl  for  case  study  A  on  the  performance  of  a  surveillance 
network  as  described  above  with  D  =  2000  bytes,  n  =  4,  Rb,  =  2000  bits/s, 
D  =  256  bits,  a  =  0.01 .  For  all  Rbl  shown,  the  latency  is  well  below  60  s. 


Increasing  the  packet  size  to  Dp  =  10000  bytes  and  keeping  the  settings  as  above 

(see  Figure  66),  requires  a  minimum  Rhl  =  6000  bits/s.  This  implies  that  MFSK 

modulation  as  described  in  Chapter  III  is  not  suitable  for  this  kind  of  network  within  the 
available  bandwidth,  when  the  packet  size  is  too  large. 

The  previous  chapter  has  shown  that  latency  depends  largely  on  the  number  of 
nodes.  Since  latency  is  a  crititcal  metric,  it  is  necessary  to  analyze  the  impact  that  the 
number  of  peripheral  nodes  has  on  the  latency  for  this  case  study.  Based  on  the  previous 
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bit  rate  analysis  and  MFSK-achievable  bit  rates,  we  set  Rhl  =3000  bits/s, 

Rh2  =  2000  bits/s,  and  let  n  =  [5,6,7,8,9,10]  while  keeping  all  other  input  parameter 

values  as  above.  For  these  settings,  the  maximum  number  of  peripheral  nodes  that  is 
allowed  by  the  latency  requirement  is  limited  to  n  =  9 .  The  results  are  shown  in  Figure 
67.  Fligher  bit  rates  would  allow  more  nodes  for  latencies  less  than  60  s;  lower  bit  rates 
would  limit  the  maximum  number  of  nodes  even  more. 


Figure  66  Effects  of  bit  rate  RIA  for  case  study  A  on  the  performance  of  a  surveillance 
network  as  described  above  with  D  =  10000  bytes,  n  =  4 ,  Rh2  =  2000  bits/s, 
D  =  256  bits,  a  =  0.01 .  For  these  settings,  at  least  Rhl  =  6000  bits/s  is  required 

to  hold  latency  to  60  s. 


Figure  67  The  number  of  nodes  has  a  profound  effect  on  latency  and  limits  the 
maximum  number  of  nodes  n  for  case  study  A  and  Rbl  =  3000  bits/s, 
Rb2  =  2000  bits/s  to  n  =  9  . 
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We  continue  the  analysis  with  the  settings  n  =  4,  Rbl  =  3000  bits/s  and 
Rb2  =  2000  bits/s  and  now  focus  on  the  network  performance  under  various  “noise” 

conditions  by  letting  a  =  [0,  0.01,  0.05,  0.1,  0.15,  0.2].  It  is  clear  from  Figure  68  that  P1D 
outperforms  T3A  in  terms  of  reliability  at  a  small  additional  cost  in  latency  of  about  two 
seconds. 


Threshold  (%)  Threshold  (%) 


Figure  68  Noisy  conditions  for  case  study  A  with  n  =  4 ,  Rbl  =  3000  bits/s  and 
Rbl  =  2000  bits/s  result  in  a  degradation  of  T3A  performance.  The  cost  in  latency 
that  has  to  be  paid  to  ensure  packet  delivery  (P1D)  is  two  seconds. 

Considering  that  P1D  is  the  most  reliable  and  suitable  network  under  all 
conditions,  we  conclude  this  study  by  determining  a  suitable  number  of  sub-packets  for 
a  =  0.1  and  letting  Dsp  =  [50,  100,  500,  1000,  2000]  as  shown  in  Figure  69.  As  is  shown 

on  the  left  plot,  Dp  =500  bytes  results  in  the  lowest  latency  for  P1D.  The  additional 

amount  of  overhead  required  for  these  sub-packets  does  not  affect  the  performance  of  the 
network  in  low-noise  situations  as  is  seen  on  the  right  plot. 

Latencies  that  can  be  expected  for  this  application  with  settings  as  described 
above  are  dependent  on  the  size  of  the  data  packet.  As  can  be  seen  in  Figure  70,  an 
increase  in  packet  size  of  two  orders  of  magnitude  results  in  unacceptably  long  latencies. 
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Figure  69  The  optimum  size  of  sub-packets  for  case  study  A  with  a  =  0.1  (left)  is 
D  p  ~  500  bytes  and  does  not  affect  the  performance  in  low-noise  conditions 

(a  =  0.01 ,  right). 


Figure  70  Latency  increases  linearly  for  D  =  [10k,  100k,  1M]  bytes. 

We  summarize  the  results  of  this  case  study  as  follows.  For  a  Seastar  application 
that  requires  high  reliability  and  has  low  latency,  P1D  appears  to  be  the  most  suitable 
network  strategy.  The  simulation  assumed  that  all  nodes  transmit  data  within  a  cycle  and 
showed  that  a  network  consisting  of  4  peripheral  nodes  is  capable  of  realizing  2  kbytes 
data  transmissions  at  realistic  data  rates  ( Rb]  =  3000  bits/s  and  Rb2  =  2000  bits/s)  with  a 

latency  that  remains  below  one  minute.  Transmitting  10-kbytes  data  packets  cannot  be 
achieved  using  MFSK  within  our  latency  restrictions.  Packet  sizes  that  are  orders  of 
magnitude  larger  in  size  result  in  unacceptably  high  latencies. 
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B.  HIGH-SPEED  TARGET  TRACKING 


To  allow  analysis  of  operational  use  of  PIE  and  T2B,  we  formulate  a  variation  on 
the  first  case  study.  Consider  a  dense  sensor  network  that  can  be  deployed  rapidly  with 
the  purpose  of  detecting  high-speed  threats  such  as  torpedoes  or  surface  vessels.  Such 
threats  require  quick  reaction  and  do  not  tolerate  long  latencies  or  large  data  packets 
containing  detailed  target  description.  A  node  will  therefore  only  report  the  detection  in 
terms  of  an  acoustic  or  electromagnetic  “hit”  due  to  the  passage  of  a  possible  target. 
Based  on  the  node’s  location,  the  threat  direction  can  be  discerned.  The  large  node 
density  allows  sensor  overlap  (redundancy)  and  short  latencies  are  preferred  over 
occasional  transmission  failures.  The  allowed  latency  is  set  to  20  s.  The  default  network 
settings  can  be  found  in  Table  8. 


Figure  71  Schematic  representation  of  a  high  density  Seastar  network  as  described  in 

case  study  B. 

The  first  parameter  that  we  analyze,  is  the  number  of  nodes  with  the  following 
settings:  Rbl  =8000  bits/s,  Rb2  =  2000  bits/s,  a  =  0.01  and  n  =  [6,  10,  14,  18,  22]  nodes. 

The  channel  utilization  and  information  throughput  are  definitely  not  optimal  but  the 
values  for  latency  look  promising  (see  Figure  72).  The  token  ring  strategies  (T2B  and 
T3A)  perform  much  better  than  the  polled  strategies  (P1D  and  P1D)  and  latencies  below 
20  seconds  for  14  nodes  are  achieved. 
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PARAMETER 

REF 

UNITS 

DEFAULT 

PARAMETER 

REF 

UNITS 

DEFAULT 

Number  of  modems 

Tl 

[] 

var 

packet  size 

DP 

[bytes] 

128 

wake  up  time 

t\vu 

[s] 

0.1 

sub-packet  size 

Dsp 

[bytes] 

128 

acquistition  time 

tacq 

[s] 

0.1 

bit  rate  (data) 

Rbl 

[bits/s] 

Var 

size  of  utility  packet 

dut 

[bytes] 

8 

bit  rate  (utility) 

Rb2 

[bits/s] 

Var 

size  of  crc 

dCrc 

[bytes] 

2 

maximum  SRQ  retries 

m.srq 

[] 

1 

size  of  header 

dnw 

[bytes] 

12 

maximum  ACK  retries 

W^ack 

[] 

1 

delay  poll-data 

tdl 

[s] 

0.4 

maximum  poll  retries 

ffl-pol! 

[] 

1 

delay  data-poll 

td2 

[s] 

0.4 

maximum  token  retries 

™  token 

[] 

1 

delay  manual 

td3 

[s] 

0 

trigger  level  0=min  l=max 

A 

[] 

Var 

delay  data-SRQ 

td4 

[s] 

0.4 

simulation  period 

T 

[hrs] 

10 

time  out  period 

td5 

[s] 

3 

simulation  repeats 

A 

[] 

10 

Table  8  Default  network  settings  for  a  high-density,  low-latency  network  (case  study  B). 


Figure  72  Effect  of  the  number  of  nodes  for  case  study  B  on  latency  for  Rbl  =  8000 
bits/s,  Rh2  =  2000  bits/s  and  a  =  0.01  shows  promising  values. 
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Assuming  that  response  times  of  20  s  are  reasonable,  our  focus  now  shifts  toward 
the  required  bit  rate.  Figure  73  shows  that  bit  rates  ( Rhl )  exceeding  2400  bits/s  (T2B)  and 

3300  bits/s  (T3A)  for  14  nodes  (n  =  14)  and  a  =  0.01  produce  latencies  below  20  s, 
meaning  that  MFSK  is  a  suitable  modulation  scheme  under  low-noise  conditions.  Noisy 
conditions,  represented  by  a  =  0.2  ,  result  in  too  much  distortion  and  latencies  exceeding 
25  s  should  be  anticipated.  Deploying  multiple  lower  density  clusters  is  a  means  to 
reduce  the  latency  even  more.  Again,  T2B  and  T3A  are  superior  in  terms  of  latency. 
Figure  74  shows  the  impact  of  the  packet  size  on  the  network  performance. 


Figure  73  Latency  versus  bit  rate  ( Rhl )  for  14  nodes  ( n  =  14 )  shown  for  a  =  0.01  (left) 

and  a  =  0.2  (right).  The  dotted  horizontal  line  marks  the  desired  20  s  latency  for 

case  study  B. 


Figure  74  Latency  versus  packet  size  ( Dp )  for  14  nodes  ( n  =  14 )  shown  for  a  =  0.01 

(left)  and  a  =  0.2  (right).  The  dotted  horizontal  line  marks  the  desired  20  s 

latency 
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In  summary,  a  Seastar  network  that  demands  a  very  low  latency  at  a  high  sensor 
density  can  only  transmit  very  compressed  data  packets.  T2B  is  by  far  the  most  suitable 
network  strategy  but  suffers  a  large  percentage  of  dropped  packets  in  noisy  environments. 
T3A  is  the  best  alternative,  allowing  some  form  of  retransmission  but  this  comes  at  the 
cost  of  a  15%  longer  latency. 

C.  MOBILE  SWARM 

The  next  case  study  involves  underwater  surveillance  using  a  swarm  of  mobile 
nodes.  As  an  example,  Figure  75  depicts  the  use  of  gliders  or  crawlers.  To  allow 
comparison  of  the  candidate  network  strategies,  the  condition  that  is  imposed  on  this  set 
of  mobile  nodes  is  that  the  swarm  maintains  its  formation  while  proceeding  through  the 
water.  The  maximum  range  from  central  node  to  the  most  distant  peripheral  node  is  500 
m,  allowing  all  neighboring  peripheral  nodes  to  communicate  with  each  other  as  well  as 
with  the  central  node.  The  central  node  collects  large  data  packets  from  the  peripheral 
nodes  and  fuses  them  into  more  compact  data  sets.  These  compiled  data  sets  can  then 
either  be  uploaded  to  a  fixed  Seaweb  node,  or  moored  gateway  buoy,  when  in  the  vicinity 
or  transmitted  via  Iridium  when  surfaced. 


Figure  75  Swarms  of  UUVs,  or  crawlers,  collecting  data,  forming  a  mobile  Seastar 

network. 
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Unlike  the  first  case  study,  this  Seastar  network  is  not  limited  by  a  latency 
requirement  since  data  uploads  from  the  central  node  are  infrequent,  non-real-time 
events.  The  type  of  data  is  left  unspecified,  but  we  assume  large  data  packets  ( Dp  =  1 

Mbyte)  that  are  collected  over  a  long  period  and,  because  of  the  relatively  large  node 
density,  an  occasional  lost  packet  is  acceptable.  The  general  settings  are  summarized  in 
Table  9,  where  “var”  refers  to  a  set  of  values  that  are  specified  through  simulation. 
Strategies  PIE  and  T2B  are  not  considered  because  of  unreliable  performance  in  noisy 
conditions. 


PARAMETER 

REF 

UNITS 

DEFAULT 

packet  size 

DP 

[bytes] 

1.000.000 

sub-packet  size 

Dsp 

[bytes] 

var 

bit  rate  (data) 

Rbl 

[bits/s] 

var 

bit  rate  (utility) 

R  i>2 

[bits/s] 

var 

maximum  SRQ  retries 

srq 

[] 

2 

maximum  ACK  retries 

m ack 

[] 

2 

maximum  poll  retries 

tnPoii 

[] 

2 

maximum  token  retries 

m  token 

[] 

2 

trigger  level  0=min  l=max 

A 

[] 

var 

simulation  period 

T 

[hrs] 

10 

simulation  repeats 

A 

[] 

100 

PARAMETER 

REF 

UNITS 

DEFAULT 

Number  of  modems 

Tl 

[] 

var 

wake  up  time 

t\vu 

[s] 

0.1 

acquistition  time 

tacq 

[s] 

0.1 

size  of  utility  packet 

dut 

[bytes] 

8 

size  of  crc 

dCrc 

[bytes] 

2 

size  of  header 

dnw 

[bytes] 

12 

delay  poll-data 

tdl 

[s] 

0.4 

delay  data-poll 

td2 

[s] 

0.4 

delay  manual 

td3 

[s] 

0 

delay  data-SRQ 

td4 

[s] 

0.4 

time  out  period 

td5 

[s] 

3 

Table  9  Settings  for  mobile  swarm  case  study.  The  value  “var”  refers  to  a  variable  that  is 

an  outcome  of  the  simulation. 

In  order  to  get  a  feeling  for  information  throughput  and  latencies  with  this  data 
packet  size,  we  first  do  a  parametric  analysis  of  bit  rate  Rbl  =  [2000,  4000,  6000,  8000, 
10000]  bits/s,  where  Rh2  =  2000  bits/s,  n  =  6  ,  Dsp  =  10  kbytes,  and  a  =  0.01 .  The  results 

(see  Figure  76)  show  latencies  in  the  order  of  hours,  which  is  unacceptably  high.  Even  if 
these  long  latencies  were  allowed,  they  would  affect  the  sensor  sampling  rate.  To 
illustrate  this,  consider  the  following  example.  Sampling  1  minute  of  data  results  in  a  1- 
Mbyte  data  packet.  It  takes  two  hours  before  all  nodes  have  transmitted  their  data 
packets,  which  implies  that  no  other  data  can  be  collected  in  that  time  frame.  This  reveals 
a  complicated  relation  between  sampling  rate,  packet  size  and  bit  rate  which  should  be 
carefully  considered. 
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Further  increasing  the  bit  rate  by  an  order  of  magnitude  is  unrealistic  and,  instead, 
we  reduce  the  packet  size  to  D  =100  kbytes.  Packet  size,  especially  in  combination 

with  a  large  number  of  nodes,  is  therefore  a  limitation  in  general  for  a  Seastar  LAN.  With 
the  reduced  packet  size,  acceptable  latencies  (8  to  13  minutes)  are  achieved  for  6  to  10 
kbits/s,  respectively  (see  Figure  77)  and  both  P1D  and  T3A  perform  well.  MFSK  is  not 
sufficient  to  achieve  these  data  rates  and  therefore  other  modulation  schemes  should  be 
explored. 


Figure  76  The  effect  of  large  data  packets  (D  =1  Mbyte)  for  case  study  C.  The  results 
show  unacceptably  high  latencies  for  Rbl  =  [2000,  4000,  6000,  8000,  10000] 

bits/s. 


Figure  77  Reduced  packet  size  ( Dp  =  100  kbytes)  shows  latencies  of  8  to  13  minutes  for 
a  total  of  n  =  6  peripheral  nodes  and  Rbl  >  6000  bits/s  (case  study  C). 
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We  now  study  the  effect  of  adjusting  the  number  of  nodes  for  two  cases.  The  first 
case  assumes  recoverable  mobile  peripheral  nodes,  allowing  the  implementation  of  more 
sophisticated  processors  that  remove  the  asymmetry  in  bit  rates.  For  this  case, 
R/a  =  R/,2  =8000  bits/s.  The  second  case  considers  disposable  mobile  peripheral  nodes 
that  use  Rbl  =8000  bits/s  but  Rh2  =  2000  bits/s.  Both  cases  assume  Dp  =100  kbytes, 
Dsp  =  10  kbytes,  a  =  0.01  and  n  =  [2,  4,  6,  8,  10,  12,  14]  nodes. 

Figure  78  shows  that  increasing  Rbl  at  these  data  rates  does  not  have  significant 

effect  on  the  latency  which  is  consistent  with  keeping  the  design  and  cost  of  the 
communications  part  of  the  peripheral  nodes  low.  The  linear  relation  between  number  of 
nodes  and  latency  and  causes  latencies  exceeding  20  minutes  for  n  >  14  nodes.  One 
possible  way  to  overcome  this  is  to  deploy  two  smaller  mobile  Seastar  networks 
collecting  data  simultaneously  while  keeping  latencies  low.  This,  however,  would  require 
measures  to  avoid  interference. 


Number  of  peripheral  nodes  Number  of  peripheral  nodes 


Figure  78  Latency  versus  number  of  modems  for  Rbl  =  Rhl  =  8000  bits/s  (left)  and 

Rbl  =  8000  bits/s  with  Rh2  =  2000  bits/s  (right). 


The  analysis  is  finalized  by  a  study  of  performance  under  the  influence  of  noise 
by  letting  a  =  [ 0,  0.01,  0.05,  0.1,  0.15,  0.2]  for  Rbl  =8000  bits/s  withRb2  =  2000  bits/s 
and  n  =  6  nodes.  Figure  79  shows  that  P1D  performs  better,  as  expected.  The  gain  of 
accepting  4%  more  dropped  packets  at  a  =  0.2  when  choosing  for  T3A  instead  of  P1D  is 
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a  10%  reduction  in  latency,  recognizing  that  the  simulation  generates  a  delaying  artificial 
packet-out-of-sequence  situation  that  may  not  be  realistic. 


Figure  79  Latency  (left)  and  dropped  packets  (right)  versus  increasing  noise  when  P1D 

is  allowed  only  2  retransmissions. 


Optimizing  for  the  size  of  sub-packets  gives  only  a  1%  improvement  in  network 
performance  (see  Figure  80).  In  order  to  avoid  abundant  overhead  in  low-noise 
conditions  D  should  not  be  less  than  2  kbytes. 


Figure  80  The  effect  of  varying  the  size  of  sub-packets  on  channel  utilization  (left)  and 

latency  (right)  for  a  =  0.1 . 


This  case  study  reveals  that  the  latency  requirement  imposes  a  restriction  on  the 
allowed  size  of  data  packets.  It  also  reveals  a  complex  relation  between  sampling  rate,  bit 
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rate,  packet  size  and  number  of  nodes.  These  issues  can  not  be  solved  by  further 
increasing  bit  rates  because  the  available  bandwidth  is  limited  and  more  sophisticated 
modulation  schemes,  such  as  PSK  or  OFDM,  are  not  yet  found  reliable  enough  for 
practical  purposes.  Solutions  have  to  be  found  at  the  application  layer  in  terms  of  data 
compression,  or  through  the  use  of  multiple  Seastar  clusters. 

For  this  case  study,  P1D  proved  to  be  the  most  reliable  network  strategy.  The 
additional  gain  in  terms  of  latency  that  T3A  gives  only  shows  up  strongly  under  noisy 
conditions.  Taking  into  account  the  additional  geometry  restriction  that  T3A  brings 
along,  the  optimum  strategy  in  a  mobile  Seastar  network  would  be  P1D. 
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VIII.  CONCLUSIONS 


A.  RESULTS 

For  a  given  transmission  range  of  500  m,  a  link  budget  analysis  has  shown  that,  in 
the  presence  of  wind,  an  optimum  carrier  frequency  can  be  found  near  41  kHz.  A 
minimum  SL  of  106  dB  re  1  pPa  @  1  m  is  required  to  achieve  a  SNRa  =  1  at  the  receiver. 

MFSK  is  the  most  robust,  readily  available  modulation  technique  for  Seastar 
underwater  acoustic  links.  An  analytical  expression  was  developed  to  evaluate  the 
relation  between  bandwidth,  optimum  number  of  bits/symbol  and  bit  rate.  The  outcome 
of  this  evaluation  depends  on  the  bandwidth  definition  of  a  sine-function.  From  a 
hardware  perspective,  the  useable  bandwidth  BWX  and  bit  rate  Ri,  are  limited  by  the 
physical  properties  of  the  transducer  but  a  BWX  of  20  kHz,  centered  near  a  carrier 
frequency  of  41  kHz,  resulting  in  maximum  R/,  of  3300  bits/s  should  be  achievable.  It 
was  theoretically  shown  that  OFDM  could  increase  R(,  by  an  order  of  magnitude  for  the 
same  BWX.  The  energy  budget  for  central  and  peripheral  modems  is  asymmetric  in  the 
sense  that  the  energy  of  the  central  node  required  to  operate  the  network  is  two  orders  of 
magnitude  larger  than  that  of  a  peripheral  node. 

A  prototype  Seastar  was  implemented  using  available  Seaweb  modems. 
Experiments  were  performed,  both  in  air  and  water,  with  the  Seastar  prototype  using  a 
polling  strategy.  The  experiments  show  that  the  concept  is  viable  and  that  the  prototype  is 
able  to  operate  persistently  without  human  intervention.  Integration  of  the  polling 
algorithm,  reduction  of  delays  and  a  smart  design  of  the  polling  utility  packet  would 
increase  the  performance  significantly.  New  modem  hardware  capable  of  transmitting  at 
higher  bit  rates  would  further  increase  the  performance. 

The  network  simulations  gave  an  insight  into  the  effect  that  certain  network 
parameters  have  on  the  performance.  For  applications  that  require  low  latency  and  accept 
low  transmission  reliability,  a  token  strategy  without  retransmissions  is  the  best 
candidate.  In  general,  however,  reliable  communications  are  required  and  therefore  SRQ- 
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capable  network  strategies  are  preferred.  Polling  with  transmission  shows  the  best 
performance  in  terms  of  reliability  whereas  token-based  networking  with  retransmission 
performs  slightly  better  in  terms  of  latency  and  information  throughput  and  channel 
utilization. 

Case  studies  confirm  the  above  conclusions  and  show  at  the  same  time  that  the 
optimum  Seastar  network  strategy  does  not  exist.  Network  optimization  fully  depends  on 
the  operational  requirements  and  boundary  conditions  that  are  imposed  upon  the  network. 

B.  RECOMMENDATIONS  FOR  FUTURE  WORK 

Future  research  should  focus  on  questions  that  have  not  been  addressed  in  this 
thesis  such  as  the  integration  of  the  Seastar  LANs  with  Seaweb  and  prevention  of  inter- 
LAN  interference.  A  study  that  includes  geometry  and  the  use  of  mobile  nodes  may 
generate  new  ideas  or  network  strategies. 

In-depth  studies  in  future  modulation  types  such  as  OFDM,  PSK  and  QAM  that 
may  apply  to  underwater  acoustic  links  are  available  but  do  not  yet  show  the  desired 
results  for  Seastar  application  in  water.  If  these  techniques  would  show  MFSK-like 
robustness,  the  network  performance  in  terms  of  bandwidth  efficiency  and  achievable  bit 
rates  would  greatly  improve.  Developments  in  this  field  should  be  closely  followed. 

Further  in-water  and  in-air  experiments  under  varying  conditions  and  in  different 
test  environments  could  improve  the  simulation  model  that  was  used  and  provide  more 
accurate  data  regarding  network  performance.  A  calibration  between  measured  noise 
levels  and  simulated  trigger  levels  would  allow  more  realistic  performance. 

C.  IMPACT 

Although  this  thesis  revealed  some  Seastar  limitations  in  terms  of  packet  size,  bit 
rate  and  latency,  the  Seastar  concept  has  the  potential  to  increase  node  density  at 
affordable  cost  to  the  US  Navy  Seaweb  wide  area  network. 
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APPENDIX  A.  POLLING  ALGORITHM  DEVELOPED  IN  C 


This  polling  algorithm  is  a  modification  to  a  code  for  allowing  communications 
with  Seaweb  modems  that  was  originally  developed  by  Chris  Fletcher  from  SPAWAR 
Systems  Center,  San  Diego.  In  order  to  reduce  the  amount  of  code  in  this  thesis,  only  the 
modified  part  containing  the  essentials  of  the  polling  algorithm  is  shown. 


/*  Polling  Algorithm  for  Seastar  Prototype 
/*  Editor:  Bjom  Kerstens 
/*  Apr-Jun  2007 

/*  Determine  input  availibity*/ 
int  result, keyboard_read; 

/*  Determine  polling  variables 

Assume  central  hub  =  address  1,  assume  peripheral  hubs  have  addresses  2-nrperiph*/ 
int  i,j,cmdsize, length; 

time_t  start, stop,  startcrashdelay,  stopcrashdelay; 
double  delay,  crashdelay; 

/*double  delay;*/ 
char  cmd[8]; 

char  *checkstrl,  *checkstr2,  *checkstr3,  *errorstrl,  *errorstr2,  ... 

*errorstr3,  *errorstr4,  *crashstrl,  *crashstr2,  *crashstr3,  ... 

*lowpstrl,  *lowpstr2,  *lowpstr3  ; 

/*  Initialize  Inputs*/ 

fd_set  inputs; 
fd_set  stdin_input; 
struct  timeval  timeout; 

FD_ZERO(  &inputs) ; 

while  (1) 

{  /*  loop  forever  until  CTRL-C*/ 

/*This  part  starts  the  polling  sequence*/ 
for(i=3;i<8;i++) 

{ 
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/*  Set  timer*/ 
timeout. tv_sec  =  0; 
timeout. tv_usec  =  500; 

LD_SET(0,&inputs); 

result  =  select/ l,&inputs,NULL,NULL,&timeout); 

/*  Check  for  Errors  */ 
if  (result  <  0) 

{ 

perror("select  failed"); 
exit(-l); 

} 

} 

/*  This  part  contains  the  polling  algorithm*/ 
else  if  (result  ==  1) 

{ 

delay=0; 

cmdsize=sprintf(cmd,"at$bt%d\r\n",i); 

if  ((atoi(argv[2])  ==  1)) 

{ 

write(STDOUT,&cmd,cmdsize); 

} 

write(fd,&cmd,cmdsize); 

write(fs,&cmd,cmdsize); 

checkstrl  =  NULL; 
checkstr2  =  NULL; 
checkstr3  =  NULL; 

errorstrl  =  NULL; 
errorstr2  =  NULL; 
errorstr3  =  NULL; 
errorstr4  =  NULL; 

crashstrl  =  NULL; 
crashstr2  =  NULL; 
crashstr3  =  NULL; 

lowpstrl  =  NULL; 
lowpstr2  =  NULL; 
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lowpstr3  =  NULL; 


/*  This  part  looks  for  strings  CRC:Pass,  Aborted  or  abort  to  determine  success  or  failure 
of  a  transmission*/ 

while(checkstrl  ==  NULL  &&  checkstr2  ==  NULL  &&  checkstr3  ==  NULL  ... 
&&  errorstrl  ==  NULL  &&  errorstr2  ==  NULL  &&  errorstr3  ==  NULL  ... 

&&  errorstr4  ==  NULL  &&  crashstrl  ==  NULL  &&  crashstr2  ==  NULL  ... 

&&  crashstr3  ==  NULL  &&  lowpstrl  ==  NULL  &&  lowpstr2  ==  NULL  && 
lowpstr3  ==  NULL) 

{ 

start=time(0); 

res=read(fd,buf,255); 

buf[res]='\0'; 

if  ((atoi(argv[2])  =  1)) 

{ 

write(STDOUT,&buf,res); 

} 


write(fs,&buf,res); 

checkstrl  =  (char  *)strstr(buf,"C:P"); 
checkstr2  =  (char  *)strstr(buf,":Pa"); 
checkstr3  =  (char  *)strstr(buf,"Pas"); 

errorstrl  =  (char  *)strstr(buf,"Abo"); 
errorstr2  =  (char  *)strstr(buf,"bor"); 
errorstr3  =  (char  *)strstr(buf,"ort"); 
errorstr4  =  (char  *)strstr(buf,"abo"); 

crashstrl  =  (char  *)strstr(buf,"WAI"); 
crashstr2  =  (char  *)strstr(buf,"AIT"); 
crashstr3  =  (char  *)strstr(buf,"IT_"); 

lowpstrl  =  (char  *)strstr(buf,"owp"); 
lowpstr2  =  (char  *)strstr(buf,"wpo"); 
lowpstr3  =  (char  *)strstr(buf,"pow"); 

if  (crashstrl  II  crashstr2  II  crashstr3  II  lowpstrl  II  lowpstr2  II  lowpstr3) 

{ 

crashdelay=0; 
startcrashdelay=time(0) ; 
while  (crashdelay<600) 

{ 
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res=read(fd,buf,255); 

buf[res]='\0'; 

if  ((atoi(argv[2])  ==  1)) 

{ 

write(STDOUT,&buf,res); 

} 

write(fs,&buf,res); 
stopcrashdelay=time(0) ; 

crashdelay=difftime(stopcrashdelay ,  startcrashdelay) ; 

} 

} 

} 

/*  Time  delay  to  prevent  cross  talk  after  "  *!*Packet  OOS"  situation*/ 
while(delay<10) 

{ 

res=read(fd,buf,255); 

buf[res]='\0'; 

string  =  (char  *)strstr(buf,">"); 

/*This  part  looks  in  buf  for  the  modem  delimiter  ">"  and  sends  a  time  stamp  to  STDOUT 
and  the  datafile*/ 

if  (string) 

{ 

(void)time(&time  val) ; 

if  ((atoi(argv[2])  ==  1)) 

{ 

write(STDOUT,ctime(&timeval),26); 

} 

write(fs,ctime(&timeval),26); 

} 

if  ((atoi(argv[2])  ==  1)) 

{ 

write(STDOUT,&buf,res); 

} 

write(fs,&buf,res); 
stop=time(0); 
delay=difftime(stop,  start) ; 

} 

} 


} 
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APPENDIX  B.  NETWORK  SIMULATION  ALGORITHMS 


The  function  INLm  is  used  to  insert  data  for  simulation  and  set  parameters.  The 
bracketed  values  are  set  up  to  contain  arrays. 


function  [number_modems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI 


number_modems=[14];  %  number  of  peripheral  modems  def=6 


t_wu=0.1; 
t_acq=0.1 ; 
d_ut=8; 
d_crc=2 ; 
d_nw=12; 


%  duration  of  wake-up  tones  [s]. 

%  duration  of  acquisition  tones  [s]. 
%  bytes  in  utility  packet. 

%  bytes  in  CRC. 

%  bytes  in  network  header. 


default=0.4 

default=0.28 

default=9 

default=2 

default=14 


t_delay1  =0.4;  %  [s]  delay  measured  btwn  poll-data  default  =1 

t_delay2=0.4;  %  [s]  delay  measured  after  data  xmit  default  =2.9 

t_delay3=0;  %  [s]  additional  delay  in  prototype  default  =0 

t_delay4=0.4;  %  [s]  delay  between  data-SRQ  order  default  =0.7 

t_delay5=3;  %  [s]  (S7)  -  acoustic  response  timeout  default  =7.5 


data_set=[64  1 28  256  51 2  1 024];  %  length  of  single  datapacket  (information)  to  be 

transmitted  [bytes] 

L_sp=[128];  %  length  of  subpacket  [bytes]  default=256 


baudratel  =[8000]; 

baudrate2=[2000]; 

maxretries=[1]; 

maxCTS=1; 

maxACK=[1]; 

maxPOLL=[1]; 

maxTOKEN=[1]; 


%  [bps]  default  =800 

%  [bps]  default  =140 

%  maximum  number  of  retries  default  =3 
%  (not  used)  default  =1 

%  maximum  number  of  ACK  retries  default  =3 

%  maximum  number  of  POLL  retries  default  =3 

%  maximum  number  of  TOKEN  retries  default  =3 


A=1 00  %  amount  of  times  that  the  simulation  will  be  executed... 

%  in  order  to  get  reliable  averages  default  =100 

T=10;  %  simulation  period  [hrs]  default  =10 

%  (e.g  T=1  means  simulate  network  for  a  period  of  1  hour) 


alfa=[0.2];  %  trigger  level  (0-1)  def=0.05 


if  alfa  ==  0 

LI  =  0,  L2  =  0,  L3  =  0,  L23(m3)  =  0,  L4(m3)  =  0; 
else 

LI  =1 ;  L2=1-alfa.*1 ;  L3=1-alfa.*2;  L23=alfa; 

L4=alfa;  L5=0; 
end 
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The  function  COLLECTDATA.m  executes  the  simulation  and  collects  the 


outcome  under  the  variable  name  “results”. 


function[results]=COLLECTDATA 
results=[POLL1d  POLLIe  TOKEN2b  TOKEN3a]; 


The  function  PLOTDATA.m  takes  the  output  of  COLLECTDATA.m  and  creates 
figures  to  display  the  results.  It  summarizes  the  input  parameters  that  were  used  for  the 
plots  under  the  variable  “settings.”  Ligures  can  be  plotted  for  one  parameter  or  two 
parameters  at  the  same  time. 


function[settings]=PLOTDATA(  results) 

[numberjnodems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 
settings=[number_modems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]; 
elf; 

%  Run  COLLECTDATA  function  FIRST  !!! 

DPARA=0; 
xname  =  0; 
yname  =  0; 

tag={'  POLLId' '  POLLIe' '  TOKEN2b' '  TOKEN3a'}; 

%  split  up  results  matrix 

SIZE  =  size(results); 

SIZEX  =  SIZE(2)/7; 

SIZEY  =  SIZE(1)/4; 

%  determine  single  parameter  or  double  parameter  plot 

if  SIZEX  >  1 
DPARA  =  1 ; 
end 

if  DPARA 

if  Iength(baudrate1)>1 
xname=  'Bit  Rate  (bits/s)'; 
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xdata  =  baudratel ; 
end 

if  length(number_modems)>1 
if  xname==0 

xname=  'Number  of  Modems'; 
xdata  =  numberjnodems; 
else 

yname=  'Number  of  Modems'; 
ydata  =  numberjnodems; 
end 
end 

if  length(data_set)>1 
if  xname==0 

xname=  'Size  of  Packet  (bytes)'; 
xdata  =  data_set; 
else 

yname=  'Size  of  Packet  (bytes)'; 
ydata  =  data_set; 
end 
end 

if  length(L_sp)>1 
if  xname==0 

xname=  'Size  of  Subpacket  (bytes)'; 
xdata  =  L_sp; 
else 

yname=  'Size  of  Subpacket  (bytes)'; 
ydata  =  L_sp; 
end 
end 

if  length(maxretries)>1 
if  xname==0 

xname=  'Number  of  POLL/TOKEN/SRQ/ACK  retries'; 
xdata  =  maxretries; 
else 

yname=  'Number  of  POLL/TOKEN/SRQ/ACK  retries'; 
ydata  =  maxretries; 
end 
end 

if  Iength(baudrate2)>1 
if  xname==0 

xname=  'Low  Bit  Rate  (bits/s)'; 
xdata  =  baudrate2; 
else 

yname=  'Low  Bit  Rate  (bits/s)'; 
ydata  =  baudrate2; 
end 
end 
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if  Iength(t_delay3)>1 
if  xname==0 

xname=  'Built-in  Delay  (s)1; 
xdata  =  t_delay3; 
else 

yname=  'Built-in  Delay  (s)1; 
ydata  =  t_delay3; 
end 
end 

xdata 

ydata 


for  i=1:3 
ii=i; 
if  ii>5; 

ii=ii+1; 

end 

figure(l) 

elf; 

subplot(3,3,ii) 

pcolor(ydata,  xdata,  results(1  :SIZEY,(i-1)*SIZEX+1  :i*SIZEX)); 

shading  interp 

xlabel(yname); 

ylabel(xname); 

caxis([0.2  0.4]); 

colorbar; 

title(strcat('Channel  Utilization' ,  tag(i))); 

figure(2) 

elf; 

subplot(3,3,ii) 

pcolor(ydata,  xdata,  results(SIZEY+1 :2*SIZEY,(i-1  )*SIZEX+1  :i*SIZEX)); 

%shading  interp 

xlabel(yname); 

ylabel(xname); 

%caxis([0.2  0.4]); 
colorbar; 

title(strcat('lnformation  Throughput' ,  tag(i))); 

figure(3) 

elf; 

subplot(3,3,ii) 

pcolor(ydata, xdata, results(2*SIZEY+1 :3*SIZEY,(i-1  )*SIZEX+1  :i*SIZEX)); 

shading  interp 

xlabel(yname); 

ylabel(xname); 

%caxis([0.2  0.4]); 
colorbar; 

title(strcat('Latency' ,  tag(i))); 
figure(4) 
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elf; 

subplot(3,3,ii) 

pcolor(ydata,xdata,results(3*SIZEY+1 :4*SIZEY,(i-1  )*SIZEX+1  :i*SIZEX)); 

%shading  interp 

xlabel(yname); 

ylabel(xname); 

caxis([0  50]); 

colorbar; 

title(strcat('Dropped  Packets' ,  tag(i))); 
end 

else 

if  Iength(baudrate1)>1 
xname  =  'Bit  rate  -  data  (bits/s)'; 
xdata  =  baudratel ; 
elseif  length(number_modems)>1 
xname  =  'Number  of  modems'; 
xdata  =  number_modems; 
elseif  length(data_set)>1 
xname=  'Size  of  packet  (bytes)'; 
xdata  =  data_set; 
elseif  length(L_sp)>1 
xname=  'Size  of  sub-packet  (bytes)’; 
xdata  =  L_sp; 
elseif  length(maxretries)>1 

xname=  ’Number  of  POLL/TOKEN/SRQ/ACK  retries'; 
xdata  =  maxretries; 
elseif  Iength(baudrate2)>1 
xname=  'Bit  rate  -  utility  packets  (bits/s)'; 
xdata  =  baudrate2; 
elseif  length(L2)>1 
xname=  'Trigger  level  (%)’; 
xdata  =  alfa*100; 
end 

figure(l) 

elf; 

plot(xdata,results(1  :SIZEY,:),'-o'); 
legend('P1  D'.'PI  E','T2B','T3A',-1); 
xlabel(xname); 
ylabel('Channel  utilization'); 

figure(2) 

elf; 

plot(xdata,results(SIZEY+1 :2*SIZEY,:),'-o'); 
legend('P1  D'.'PI  E','T2B'1'T3A',-1); 
xlabel(xname); 

ylabel('lnformation  throughput  (bits/s)'); 

figure(3) 

elf; 

plot(xdata,results(2*SIZEY+1 :3*SIZEY,:),'-o'); 
legend('P1  D'.'PI  E','T2B','T3A',-1); 
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xlabel(xname); 
ylabel('Latency  (s)'); 

figure(4) 

elf; 

plot(xdata,results(3*SIZEY+1 :4*SIZEY,:),'-o'); 
legend('P1  D','P1  E','T2B',T3A',-1); 
xlabel(xname); 

ylabel('Dropped  packets  (%)'); 
end 


The  function  POLLld.m  is  used  to  simulate  network  strategy  P1D. 


function[result1  d,  energyl d]=POLL1  d 
clear, 


O/  ************************************************************************ 

/o 

% 

%  Initiate  values  through  <ini.m>  function 

% 

Q/  ************************************************************************ 

/O 

[number_modems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

for  m1=1:length(baudrate1)  %  baudratel 

for  m2=1  :length(data_set)  %  data  length 

for  m3=1  :length(L2)  %  noise 

for  m4=1  :length(maxretries)  %  maxretries 

for  m5=1  :length(L_sp)  %  subpacket  length 

for  m6=1  :length(number_modems)  %  number_modems 

for  m7=1  :length(baudrate2)  %  baudrate2 

%  calculate  #  subpackets  and  duration  of  utility  packet 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5));  %number  of  subpackets 

t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq;  %  transmission  time  of  utility  packet 


Q/  ************************************************************************ 

/O 

% 

%  Do  the  simulation  a  couple  of  times  to  get  a  good  average  of  the 
%  metrics  you're  interested  in 

% 

O/  ************************************************************************* 

/o 


for  a=1  :A;  %  run  simulation  'a'  times 

%  reset  all  values  to  zero 


126 


OOS=0; 

DOOS=0; 

00SFLAG(1  :number_modems(m6))=0; 
00SFLAG1  =0; 

OOSFLAG2=0; 

REPOLL=1; 

d_total=0; 

t_total=0; 

Iatency1=0; 

latency(a)=0; 

pktabort(a)=0; 

pktcorrect(a)=0; 

d_modem1  (1  :number_modems(m6),1  )=0; 
d_modem2(1  :number_modems(m6),1  )=0; 

t_modem1  (1  :number_modems(m6),1  )=0; 
t_modem2(1  :numberjriodems(m6),1)=0; 

cycle=1 ; 


O/  ********************** 

/o 

%energy  calc,  only  III 
TP=0; 

Tl=0; 

Wrcv=0.5;  %[W] 
Wxmt=0.1;  %[W] 

O/  ********************* 

/o 


while  t_total<(3600*T) 


for  address=1  :number_modems(m6); 


O/  ********************************************************************* 

/o 

%  In  case  OOSFLAG  flag  is  set  to  1 ,  the  transmission  consists  of  the  new 
%  packet  sent  at  bit  ratel  and  the  old  packet  at  bit  rate2 

Q/  ********************************************************************* 

/O 


if  OOSFLAG(address) 

[OOS,  DOOS,  OOSFLAG  1]=oos(m1  ,m2,m3,m4,m5,m6,m7,... 
OOSFLAG(address), REPOLL); 

OOSFLAG(address)  =  OOSFLAG  1 ; 

end 


Q/  ********************************************************** 

/O 

%  info  packet 

Q/  ********************************************************** 

/O 
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[INFO,  DAT  A]=info(m1,  m2,  m3,  m4,m5,m6,m7,  REPOLL); 


dice1=rand(1); 


Q/  ********************************************************** 

/o 

%  utility  or  info  packet  corrupted 

Q/  ********************************************************** 

/o 


[SRQ,DATA,OOSFLAG2]=  srql  (ml  ,m2,m3,m4,m5,m6,m7,dice1 ,... 
OOSFLAG2, REPOLL); 

OOSFLAG(address)  =  OOSFLAG2; 


Q/  ********************************************************** 

/O 

%  POLLING  utility  packet 

Q/  ********************************************************** 

/o 


[POLL,POLLFLAG]=poll(m1  ,m2,m3,m4,m5,m6,m7,dice1 , REPOLL); 

if  POLLFLAG 
INFO=0;  OOS=0; 

DATA=0;  DOOS=0; 

OOSFLAG(address)=1 ; 
end 


Q/  ********************************************************** 

/o 

%  add  all  events 

Q/  ********************************************************** 

/o 


t_xmit=POLL+INFO+SRQ+OOS; 

data(m2)=DATA+DOOS; 

if  (DATA==0)  &  (POLLFLAG==0) 
pktabort(a)=pktabort(a)+1 ; 
elseif  DATA~=0; 

pktcorrect(a)=pktcorrect(a)+1 ; 
end 

t_modem1  (address,  cycle+1)=t_modem1  (address,  cycle)+t_xmit; 
t_modem2(address,cycle+1)=t_xmit; 

djnodeml  (address,cycle+1)=d_modem1  (address, cycle)+data(m2)*8; 
d_modem2(address,cycle+1)=data(m2)*8; 

DATA=data_set(m2);  %resetdata 
OOS=0;  %reset  OOSFLAG  correction 

DOOS^O;  %reset  OOSFLAG  correction 

OOSFLAG1=0; 

OOSFLAG2=0; 

counter=counter+1 ; 


n/  ************************************************************ 
/O 
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%  ENERGY  BUDGET:  ONLY  IN  NOISE  FREE  SIMULATION!!!!!! 
%  Instruction:  set  A=1 ;  T=1 ;  Only  for  single  input  parameter 

O/  ************************************************ 

/o 

%  TP  =  TP  +  POLL  -  t_delay1 ; 

%  Tl  =  Tl  +  INFO  -  (t_delay2+t_delay3); 

%  Prcv  =  TP*Wrcv; 

%  Pxmt  =  (TI)*Wxmt; 

%  Phr  =  (Prcv+Pxmt)/number_modems(m6); 

%  Crcv  =  (TI)*Wrcv; 

%  Cxmt  =  TP*Wxmt; 

%  Chr  =  (Crcv+Cxmt); 

%  energy1a=[Phr;  Chr]; 

Q/  ********************************************************** 

/o 


end  %  end  “for”  loop  that  determines  modem  addresses 

t_total(1  ,cycle+1)=t_total(1  ,cycle)+sum(t_modem2(:,cycle+1)); 
d_total(1  ,cycle+1  )=d_total(1  ,cycle)+sum(d_modem2(:,cycle+1 )); 
latencyl  (1  ,cycle)=sum(t_modem2(:,cycle+1 )); 

cycle=cycle+1 ; 

end  %  end  “while”  loop  -  period  that  network  is  evaluated 


O/  ********************************************************************* 

/o 

%  utilization=t_information/t_total 
% 

%  throughput  =  actual  baudrate  so  average  actual  amount  of  bits  you  can 
%  transfer  from  peripheral  to  central  considering  present  settings 

% 

%  latency  =  the  maximum  period  that  you  should  have  to  wait  to  receive 
%  data  from  a  specific  address 

Q/  ********************************************************************* 

/O 


utilization(a)=(d_total(1,length(d_total))/baudrate1(m1))  / ... 
(t_total(1  ,length(t_total))); 


throughput(a)=(d_total(1  ,length(d_total)))  / ... 
(t_total(1 ,  length  (t_total))) ; 


Iatency(a)=mean(latency1 ); 


pktabort(a)=100*pktabort(a)/(  pktcorrect(a)+pktabort(a) ); 


end 


util_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(utilization); 


throughput_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(throughput); 


Iatency_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(latency); 
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pktabort_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(pktabort); 


end 

end 

end 

end 

end 

end 

end 

util_ave=squeeze(shiftdim(util_ave)); 

throughput_ave=squeeze(shiftdim(throughput_ave)); 

latency_ave=squeeze(shiftdim(latency_ave)); 

pktabort_ave=squeeze(shiftdim(pktabort_ave)); 

resultl d=[util_ave;  throughput_ave;  latency_ave;  pktabort_ave]; 


The  function  POLLle.m  is  used  to  simulate  network  strategy  PIE. 


function[result1  e,  energyl  e]=POLL1  e 
clear, 

O/  ************************************************************************ 

/o 

% 

%  Initiate  values  through  <ini.m>  function 

% 

Q/  ************************************************************************ 

/O 

[number_modems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

for  m1=1:length(baudrate1)  %  baudratel 

for  m2=1  :length(data_set)  %  data  length 

for  m3=1  :length(L2)  %  noise 

for  m4=1  :length(maxretries)  %  maxretries 

for  m5=1  :length(L_sp)  %  subpacket  length 

for  m6=1  :length(number_modems)  %  number_modems 

for  m7=1  :length(baudrate2)  %  baudrate2 

%  calculate  #  subpackets  and  duration  of  utility  packet 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5));  %number  of  subpackets 
t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq;  %  transmission  time  of  utility  packet 


o/  ************************************************************************ 

/o 

% 

%  Do  the  simulation  a  couple  of  times  to  get  a  good  average  of  the 
%  metrics  you're  interested  in 

% 
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Q/  ************************************************************************* 

/O 


for  a=1  :A;  %  run  simulation  'a'  times 

%  reset  all  values  to  zero 

REPOLL=0; 

d_total=0; 

t_total=0; 

Iatency1=0; 

latency(a)=0; 

pktabort(a)=0; 

pktcorrect(a)=0; 

d_modem1  (1  :number_modems(m6),1  )=0; 
d_modem2(1  :number_modems(m6),1  )=0; 

t_modem1  (1  :number_modems(m6),1)=0; 
t_modem2(1  :number_modems(m6),1)=0; 

cycle=1 ; 

Q/  ********************** 

/O 

%energy  calc,  only  !!! 

TP=0; 

Tl=0; 

Wrcv=0.5;  %[W] 

Wxmt=0.1 ;  %[W] 

Q/  ********************* 

/O 


while  t_total<(3600*T) 
for  address=1  :number_modems(m6); 


Q/  ********************************************************** 

/o 

%  info  packet 

Q/  ********************************************************** 

/O 


[INFO,  DAT  A]=info(m1,  m2,  m3,  m4,m5,m6,m7,  REPOLL); 


Q/  ********************************************************** 

/O 

%  utility  or  info  packet  corrupted 

o/  ********************************************************** 
/o 


dice1=rand(1); 


if  ((dicel  <L2(m3))  &  (dicel  >=L3(m3))) 
DATA=0; 
end 
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Q/  ********************************************************** 

/O 

%  POLLING  utility  packet 

o/  ********************************************************** 
/O 


[POLL,POLLFLAG]=poll(m1  ,m2,m3,m4,m5,m6,m7,dice1 , REPOLL); 


if  POLLFLAG 


POLL  =  2*POLL; 

dice4=rand(1); 
if  dice4  <  L4(m3) 
INFO=0;  DATA=0; 
end 
end 


Q/  ********************************************************** 

/o 

%  add  all  events 

Q/  ********************************************************** 

/o 


t_xmit=POLL+INFO; 

data(m2)=DATA; 

if  DATA==0 

pktabort(a)=pktabort(a)+1 ; 
else 

pktcorrect(a)=pktcorrect(a)+1 ; 
end 

t_modem1  (address,  cycle+1)=t_modem1  (address,  cycle)+t_xmit; 
t_modem2(address,cycle+1)=t_xmit; 

d_modem1  (address,cycle+1)=d_modem1  (address,  cycle)+data(m2)*8; 
d_modem2(address,cycle+1)=data(m2)*8; 

DATA=data_set(m2);  %resetdata 

counter=counter+1 ; 


O/  ************************************************************ 

/o 

%  ENERGY  BUDGET:  ONLY  IN  NOISE  FREE  SIMULATION!!!!!! 
%  Instruction:  set  A=1 ;  T=1 ;  Only  for  single  input  parameter 

O/  ************************************************ 

/o 

%  TP  =  TP  +  POLL-t_delay1 ; 

%  Tl  =  Tl  +  INFO  -  (t_delay2+t_delay3); 

%  Prcv  =  TP*Wrcv; 

%  Pxmt  =  (TI)*Wxmt; 

%  Phr  =  (Prcv+Pxmt)/number_modems(m6); 

%  Crcv  =  (TI)*Wrcv; 

%  Cxmt  =  TP*Wxmt; 

%  Chr  =  (Crcv+Cxmt); 

%  energyl c=[Phr;  Chr]; 

Q/  ********************************************************** 

/O 
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end  %  end  for  loop  that  determines  modem  addresses 

t_total(1  ,cycle+1  )=t_total(1  ,cycle)+sum(t_modem2(:,cycle+1 )); 
d_total(1  ,cycle+1)=d_total(1  ,cycle)+sum(d_modem2(:,cycle+1)); 
latencyl  (1  ,cycle)=sum(t_modem2(:,cycle+1)); 

cycle=cycle+1 ; 

end  %  end  while  loop  -  period  that  network  is  evaluated 

O  /  ********************************************************************* 

/o 

%  utilization=tJnformation/t_total 

% 

%  throughput  =  actual  baudrate  so  average  actual  amount  of  bits  you  can 
%  transfer  from  peripheral  to  central  considering  present  settings 

% 

%  latency  =  the  maximum  period  that  you  should  have  to  wait  to  receive 
%  data  from  a  specific  address 

Q  /  ********************************************************************* 

/o 

utilization(a)=(d_total(1  ,length(d_total))/baudrate1  (ml ))  / ... 

(t_total(1  ,length(t_total))); 

throughput(a)=(d_total(1,length(d_total)))  / ... 

(t_total(1  ,length(t_total))); 

Iatency(a)=mean(latency1 ); 

pktabort(a)=100*pktabort(a)/(  pktcorrect(a)+pktabort(a) ); 
end 

util_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(utilization); 

throughput_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(throughput); 

Iatency_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(latency); 

pktabort_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(pktabort); 

end 

end 

end 

end 

end 

end 

end 

util_ave=squeeze(shiftdim(util_ave)); 

throughput_ave=squeeze(shiftdim(throughput_ave)); 


133 


Iatency_ave=squeeze(shiftdim(latency_ave)); 

pktabort_ave=squeeze(shiftdim(pktabort_ave)); 

resultl e=[util_ave;  throughput_ave;  latency_ave;  pktabort_ave]; 


The  function  TOKEN2b.m  is  used  to  simulate  network  strategy  T2B. 


function[result2b,  energy2b]=TOKEN2b 
clear, 

Q/  ************************************************************************ 

/o 

% 

%  Initiate  values  through  <ini.m>  function 

% 

O/  ************************************************************************ 

/o 

[number_modems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

for  m1=1:length(baudrate1)  %  baudratel 

for  1712=1  :length(data_set)  %  data  length 

for  m3=1  :length(L2)  %  noise 

for  m4=1  :length(maxretries)  %  maxretries 

for  m5=1  :length(L_sp)  %  subpacket  length 

for  m6=1  :length(number_modems)  %  number_modems 

for  m7=1  :length(baudrate2)  %  baudrate2 

%  calculate  #  subpackets  and  duration  of  utility  packet 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5));  %number  of  subpackets 
t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq;  %  transmission  time  of  utility  packet 


Q/  ************************************************************************ 

/o 

% 

%  Do  the  simulation  a  couple  of  times  to  get  a  good  average  of  the 
%  metrics  you're  interested  in 

% 

Q/  ************************************************************************* 

/o 


for  a=1  :A;  %  run  simulation  'a'  times 

%  reset  all  values  to  zero 

RETOKEN=0; 

HUB=0; 


d_total=0; 

t_total=0; 

Iatency1=0; 
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latency(a)=0; 

pktabort(a)=0; 

pktcorrect(a)=0; 

d_modem1  (1  :number_modems(m6),1  )=0; 
d_modem2(1  :number_modems(m6),1  )=0; 

t_modem1  (1  :number_modems(m6),1  )=0; 
t_modem2(1  :numberjriodems(m6),1)=0; 

cycle=1 ; 


Q/  ********************** 

/O 

%energy  calc,  only  III 
TT=0; 

Tl=0; 

Wrcv=0.5;  %[W] 
Wxmt=0.1 ;  %[W] 

Q/  ********************* 
/O 


while  t_total<(3600*T) 


for  address=1  :number_modems(m6); 


Q/  ********************************************************** 

/O 

%  info  packet 

Q/  ********************************************************** 

/O 

[INFO,  DAT  A]=info(m1,  m2,  m3,  m4,m5,m6,m7,  RETOKEN); 
%[INFO,DATA]=info(m1  ,m2,m3,m4,m5,m6,m7); 

Q/  ********************************************************** 

/O 

%  utility  or  info  packet  corrupted 

Q/  ********************************************************** 

/O 


dice1=rand(1); 

if  ((dicel  <L2(m3))  &  (dicel  >=L3(m3))) 
DATA=0; 
end 


Q/  ********************************************************** 

/O 

%  TOKEN  utility  packet 

Q/  ********************************************************** 

/O 


[TOKEN, TOKENFLAG]=token(m1, m2, m3, m4,m5,m6,m7, dicel, RETOKEN, HUB); 

TOKEN  =  TOKEN  -  t_delay1 ; 

if  TOKENFLAG 
INFO=0; 

DATA=0; 

end 
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Q/  ********************************************************** 

/O 

%  add  all  events 

Q/  ********************************************************** 

/O 


t_xmit=TOKEN+INFO; 

data(m2)=DATA; 

if  DATA==0 

pktabort(a)=pktabort(a)+1 ; 
else 

pktcorrect(a)=pktcorrect(a)+1 ; 
end 

tjmodeml  (address,  cycle+1  )=t_modem1  (address, cycle)+t_xmit; 
t_modem2(address,cycle+1)=t_xmit; 

djnodeml  (address, cycle+1  )=d_modem1  (address,  cycle)+data(m2)*8; 
d_modem2(address,  cycle+1  )=data(m2)*8; 

DATA=data_set(m2);  %reset  data 

OOS=0;  %reset  OOSFLAG  correction 

DOOS=0;  %reset  OOSFLAG  correction 

counter=counter+1 ; 


Q/  ************************************************************ 

/O 

%  ENERGY  BUDGET:  ONLY  IN  NOISE  FREE  SIMULATION!!!!!! 
%  Instruction:  set  A=1 ;  T=1 ;  Only  for  single  input  parameter 

Q/  ************************************************ 

/O 

%  TT  =  TT  + TOKEN; 

%  Tl  =  Tl  +  INFO  -  (t_delay2+t_delay3); 

%  Prcv  =  (TT)*Wrcv; 

%  Pxmt  =  (TI)*Wxmt; 

%  Phr  =  (Prcv+Pxmt)/number_modems(m6); 

%  Crcv  =  (TI)*Wrcv; 

%  Cxmt  =  (TT)*Wxmt; 

%  Chr  =  (Crcv+Cxmt); 

%  energy2b=[Phr;  Chr]; 

O/  ********************************************************** 

/o 


end  %  end  for  loop  that  determines  modem  addresses 

t_total(1 , cycle+1  )=t_total(1  ,cycle)+sum(t_modem2(:,  cycle+1 )); 
d_total(1 , cycle+1  )=d_total(1  ,cycle)+sum(d_modem2(:, cycle+1 )); 
latencyl  (1  ,cycle)=sum(t_modem2(:, cycle+1 )); 

cycle=cycle+1 ; 

end  %  end  while  loop  -  period  that  network  is  evaluated 

Q/  ********************************************************************* 

/o 

%  baudrateact  =  actual  baudrate  so  average  actual  amount  of  bits  you  can 
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%  transfer  from  peripheral  to  central  considering  present  settings 

% 

%  utilization=t_information/t_total 
% 

%  latency  =  the  maximum  period  that  you  should  have  to  wait  to  receive 
%  data  from  a  specific  address 

o/  ********************************************************************* 

/o 


throughput(a)=(d_total(1  ,length(d_total)))  /  (t_total(1  ,length(t_total))); 
utilization(a)=(d_total(1  ,length(d_total))/baudrate1  (ml ))  /  (t_total(1  ,length(t_total))); 
Iatency(a)=mean(latency1 ); 

pktabort(a)=100*pktabort(a)/(  pktcorrect(a)+pktabort(a) ); 
end 

util_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(utilization); 

throughput_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(throughput); 

Iatency_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(latency); 

pktabort_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(pktabort); 

end 

end 

end 

end 

end 

end 

end 

util_ave=squeeze(shiftdim(util_ave)); 
throughput_ave=squeeze(shiftdim(throughput_ave)); 
latency_ave=squeeze(shiftdim(latency_ave)); 
pktabort_ave=squeeze(shiftdim(pktabort_ave)); 
result2b=[util_ave;  throughput_ave;  latency_ave;  pktabort_ave]; 


The  function  TOKEN3a.m  is  used  to  simulate  network  strategy  T3A. 


function[result3a,  energy3a]=TOKEN3a 


clear, 


O/  ************************************************************************ 

/o 

% 
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%  Initiate  values  through  <ini.m>  function 

% 

Q/  ************************************************************************ 

/O 

[numberjnodems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

for  m1=1:length(baudrate1)  %  baudratel 

for  m2=1  :length(data_set)  %  data  length 

for  m3=1  :length(L2)  %  noise 

for  m4=1  :length(maxretries)  %  maxretries 

for  m5=1  :length(L_sp)  %  subpacket  length 

for  m6=1  :length(number_modems)  %  number_modems 

for  m7=1  :length(baudrate2)  %  baudrate2 

%  calculate  #  subpackets  and  duration  of  utility  packet 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5));  %number  of  subpackets 
t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq;  %  transmission  time  of  utility  packet 


o/  ************************************************************************ 

/o 

% 

%  Do  the  simulation  a  couple  of  times  so  you  get  a  good  average  of  the 
%  metrics  you're  interested  in 

% 

0/  ************************************************************************* 

/o 


for  a=1  :A;  %  run  simulation  'a'  times 

%  reset  all  values  to  zero 


OOS=0; 

DOOS=0; 

SRQ=0; 


DSRQ^O; 

MEMFLAG(1  :number_modems(m6),1)=0; 
MEMFLAG(1  :number_modems(m6),2)=0; 
RET0KEN=1 ; 


HUB=1; 


d_total=0; 

t_total=0; 

t_centrai=0; 

Iatency1=0; 

iatency(a)=0; 

pktabort(a)=0; 

pktcorrect(a)=0; 

d_modem1  (1  :number_modems(m6),1  )=0; 
d_modem2(1  :number_modems(m6),1  )=0; 

t_modem1  (1  :number_modems(m6),1  )=0; 
t_modem2(1  :number_modems(m6),1)=0; 
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cycle=1 ; 


Q/  ********************** 

/O 

%energy  calc,  only  III 
TT=0; 

Tl=0; 

Wrcv=0.5;  %[W] 
Wxmt=0.1;  %[W] 

Q/  ********************* 

/O 


while  t_total<(3600*T) 


for  address=1  :number_modems(m6); 


Q/  ************************************************************** 

/o 

%  In  case  MEMFLAG(address,2)  is  set  to  1  the  previous  packet 
%  was  out-of-sequence.  The  packet  will  be  retransmitted  at 
%  baudrate2.  If  retransmission  fails,  the  packets  gets  aborted 

Q/  ************************************************************** 

/o 


if  MEMFLAG(address,2) 

[OOS,DOOS]=mem2(m1  ,m2,m3,m4,m5,m6,m7); 
MEMFLAG(address,2)  =  0; 
if  DOOS==0 

pktabort(a)=pktabort(a)+1 ; 
else 

pktcorrect(a)=pktcorrect(a)+1 ; 
end 

end 


Q/  ************************************************************** 

/o 

%  In  case  MEMFLAG(address,1)  is  set  to  1  the  previous  packet 
%  was  corrupted.  The  packet  will  be  retransmitted  at 
%  baudratel.  If  retransmission  fails,  the  packets  gets  aborted 

Q/  ************************************************************** 

/O 

if  MEMFLAG(address,1) 

[SRQ,DSRQ]=mem1  (ml  ,m2,m3,m4,m5,m6,m7); 
MEMFLAG(address,1)  =  0; 
if  DSRQ==0 

pktabort(a)=pktabort(a)+1 ; 
else 

pktcorrect(a)=pktcorrect(a)+1 ; 
end 
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end 


Q/  ********************************************************** 

/o 

%  info  packet 

Q/  ********************************************************** 

/o 


[INFO,  DAT  A]=info(m1,  m2,  m3,  m4,m5,m6,m7,  RETOKEN); 


dice1=rand(1); 


Q/  ********************************************************** 

/o 

%  utility  or  info  packet  corrupted:  MEMFLAG(address,1)  is 
%  set  to  1  and  no  data  is  transmitted 

Q/  ********************************************************** 

/o 

dice1=rand(1); 

if  ((dice1<L2(m3))  &  (dice1>=L3(m3))) 

MEMFLAG(address,1)  =  1;  %  Subpacket/header  corrupted 

DATA  =  0; 
end 


Q/  ★★★*****★★★****★* ★*★*****★★★★★*******★★★★***** ★★★*****★★★* 

/o 

%  TOKEN  utility  packet;  if  token  is  corrupted,  the  central 
%  node  will  retransmit  token  until  maxtoken  is  achieved. 

%  If  maxtoken  is  needed,  TOKENFLAG  =  1  and  MEMFLAG(address,2) 
%  is  set  to  1  which  will  generate  packet  out  of  sequence. 

%  No  data  transmission  will  occur  and  the  packet  will  be  rexmit 
%  at  next  cycle 

Q/  ★★★*****★*★***★★*★★★*****★★★★★*★★★★★★★★★★***** ★*★***★★★★★★ 

/o 


[TOKEN, TOKENFLAG]=token(m1, m2, m3, m4,m5,m6,m7,dice1, RETOKEN, HUB); 
if  TOKENFLAG 


MEMFLAG(address,2)  =  1;  %  Token  corrupted,  PKT  OOS 

MEMFLAG(address,1)  =  0; 

INFO=0;  OOS=0; 

DATA=0;  DOOS=0;  DSRQ=0; 


end 


Q/  ********************************************************** 

/O 

%  add  all  events 

Q/  ********************************************************** 

/O 


t_xmit=TOKEN+INFO+SRQ+OOS; 
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data(m2)=DATA+D00S+DSRQ; 


if  DATA  ~=  0 

pktcorrect(a)=pktcorrect(a)+1 ; 
end 


Q/  ************************************************************ 

/o 

%  ENERGY  BUDGET:  ONLY  IN  NOISE  FREE  SIMULATION!!!!!! 
%  Instruction:  set  A=1 ;  T=1 ;  Only  for  single  input  parameter 

Q/  ************************************************ 

/O 

%  TT  =  TT  + TOKEN; 

%  Tl  =  Tl  +  INFO  -  (t_delay2+t_delay3); 

%  Prcv  =  TT*Wrcv; 

%  Pxmt  =  (TT+TI)*Wxmt; 

%  Phr  =  (Prcv+Pxmt)/number_modems(m6); 

%  Crcv  =  (TT+TI)*Wrcv; 

%  Cxmt  =  TT*Wxmt/number_modems(m6); 

%  Chr  =  (Crcv+Cxmt); 

%  energy3a=[Phr;  Chr]; 

O/  ********************************************************** 

/o 


t_modem1  (address,  cycle+1)=t_modem1  (address,  cycle) +t_xm  it; 
t_modem2(address,cycle+1)=t_xmit; 

djmodeml  (address,  cycle+1  )=d_modem1  (address,  cycle)+data(m2)*8; 
d_modem2(address,cycle+1)=data(m2)*8; 

DATA=data_set(m2);  %reset  data 

OOS=0;  %reset  OOSFLAG  correction 

DOOS=0;  %reset  OOSFLAG  correction 

SRQ=0; 

DSRQ=0; 

counter=counter+1 ; 

end  %  end  for  loop  that  determines  modem  addresses 


Q/  ***************************************************************** 

/o 

%  Add  contribution  of  central  hub  included  in  cycle:  only  1  token 
%  will  be  generated.  If  the  token  from  the  last  peripheral  modem  to 
%  the  central  modem  fails,  the  central  modem  knows  that  it  was  its 
%  turn  to  transmit  so  it  won;t  initiate  a  new  token 

Q/  ***************************************************************** 

/o 

t_central(1 , cycle)  =  t_wu  +  t_acq  +  ... 

(number_modems(m6)*2  +  d_ut  +  d_crc)*8/baudrate2(m7)  +  t_delay4; 

t_total(1 , cycle+1  )=t_total(1  ,cycle)+t_central(1  .cycle)... 

+sum(t_modem2(:,  cycle+1 )); 

d_total(1 , cycle+1  )=d_total(1  ,cycle)+sum(d_modem2(:,  cycle+1 )); 
latencyl  (1  ,cycle)=sum(t_modem2(:, cycle+1 )); 

cycle=cycle+1 ; 
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end 


%  end  while  loop  -  period  that  network  is  evaluated 


Q/  ********************************************************************* 

/O 

%  baudrateact  =  actual  baudrate  so  average  actual  amount  of  bits  you  can 
%  transfer  from  peripheral  to  central  considering  present  settings 

% 

%  utilization=t_information/t_total 
% 

%  latency  =  the  maximum  period  that  you  should  have  to  wait  to  receive 
%  data  from  a  specific  address 

o /  ********************************************************************* 

/o 


throughput(a)=(d_total(1  ,length(d_total)))  /  (t_total(1  ,length(t_total))); 
utilization(a)=(d_total(1  ,length(d_total))/baudrate1  (ml ))  /  (t_total(1  ,length(t_total))); 
Iatency(a)=mean(latency1 ); 

pktabort(a)=100*pktabort(a)/(  pktcorrect(a)+pktabort(a) ); 
end 

util_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(utilization); 

throughput_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(throughput); 

Iatency_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(latency); 

pktabort_ave(m1  ,m2,m3,m4,m5,m6,m7)=mean(pktabort); 

end 

end 

end 

end 

end 

end 

end 

util_ave=squeeze(shiftdim(util_ave)); 
throughput_ave=squeeze(shiftdim(throughput_ave)); 
latency_ave=squeeze(shiftdim(latency_ave)); 
pktabort_ave=squeeze(shiftdim(pktabort_ave)); 
result3a=[util_ave;  throughput_ave;  latency_ave;  pktabort_ave]; 
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The  function  poll.m  performs  polling  simulation. 


function  [POLL,POLLFLAG]=poll(m1  ,m2,m3,m4,m5,m6,m7,dice1 , REPOLL) 

[numberjriodems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 

t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq; 

if  ((dicelcLI)  &  (dice1>=L2(m3))) 

POLLcount=1 ; 
if  REPOLL 

while  POLLcount  <  maxPOLL(m4) 
dice4=rand(1); 
if  dice4  <  L4(m3) 

POLLcount=POLLcount+1 ; 
else 
break 
end 
end 


end 

POLL  =  POLLcount  *  sum([t_wu  t_ut  t_delay5  t_delay3]); 
if  ( (REPOLL  ==  0)  |  (POLLcount  ==  maxPOLL(m4)) ) 
POLLFLAG  =  1 ; 
else 

POLLFLAG  =  0; 
end 
else 

POLL  =  sum([t_wu  t_ut  t_delay1  ]); 

POLLFLAG  =  0; 
end 
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The  function  token.m  performs  token  simulation. 


function  [TOKEN, TOKENFLAG]=token(m1  ,m2,m3,m4,m5,m6,m7,dice1 , RETOKEN, HUB) 

[number_modems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

if  HUB 

t_token  =  t_wu  +  t_acq  +  (number_modems(m6)*2  +  d_ut  +  d_crc)*8/baudrate2(m7); 
TOKEN  =  t_token; 
else 

t_token=t_acq  +  t_wu  +  (d_ut+d_crc)*8/baudrate2(m7); 

TOKEN  =  t_token  +  t_delay1 ; 
end 

TOKENFLAG  =  0; 

if  ((dicelcLI)  &  (dice1>=L2(m3))) 

TOKENcount=1 ; 

if  RETOKEN  ==  0 
maxTOKEN(m4)  =  1; 
end 

while  TOKENcount  <=  maxTOKEN(m4) 
dice4=rand(1); 
if  dice4  <  L4(m3) 

TOKENcount=TOKENcount+1 ; 
else 
break 
end 
end 

if  (  TOKENcount  >  maxTOKEN(m4) ) 

TOKENcount  =  maxTOKEN(m4); 

TOKENFLAG  =  1; 
end 

TOKEN  =  TOKEN  +  TOKENcount  *  sum([t_token  t_delay5  t_delay3]); 


end 
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The  function  info.m  generates  data  packets. 


function  [INFO, DAT A]=info(m1  ,m2,m3,m4,m5,m6,m7,type) 

[numberjnodems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq; 

if  type  ==  0 
N_sp(m5)=1; 
else 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5)); 

end 

INFO  =  sum([t_wu  t_ut  (data_set(m2)+N_sp(m5)*d_crc+d_nw)*8/baudrate1  (ml)... 
t_delay2  t_delay3]); 

DATA  =  data_set(m2); 


The  function  oos.m  creates  packets  that  are  retransmitted  upon  packet-out-of¬ 
sequence  situation. 


function  [OOS,DOOS,OOSFLAG]=oos(m1,m2,m3,m4,m5,m6,m7,OOSFLAG,REPOLL) 

[numberjnodems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq; 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5)); 

dicel  =(L3(m3)+L2(m3))/2; 

[SRQ,DATA,OOSFLAG]=  srql  (ml  ,m2,m3,m4,m5,m6,m7,dice1  ,OOSFLAG,  REPOLL); 

if  DATA  ==  0 
ACK  =  0; 

else 

[ACK]=ack(m1  ,m2,m3,m4,m5,m6,m7,OOSFLAG); 
end 

OOS  =  SRQ  +  ACK; 

DOOS  =  DATA; 


145 


The  function  srql.m  determines  what  kind  of  unsuccessful  initial  transmission 
occurs  and  how  the  retransmission  is  performed. 


function  [SRQ,DATA,OOSFLAG]=  srql  (ml  ,m2,m3,m4,m5,m6,m7,dice1  ,OOSFLAG, REPOLL) 

[numberjnodems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq; 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5)); 

if  ((dicel  <L2(m3))  &  (dice1>=L3(m3))) 

dice2=rand(1); 

for  i=1  :(N_sp(m5)) 

if  ( (dice2<(i/N_sp(m5)))  &  (dice2>=(i-1)/N_sp(m5)) ) 
dice3=rand(1); 

Q/  ********************************************************** 

/o 

%  header  corrupted  (causes  packet  out  of  sequence) 

%  subpacket  corrupted  +  SRQ  corrupted 

Q/  ********************************************************** 

/o 

if  (dice3<L23(m3)) 
if  REPOLL 
i=N_sp(m5); 

[SRQ, DATA]  =  srq2(m1  ,m2,m3,m4,m5,m6,m7,i,OOSFLAG); 

OOSFLAG  =  0; 
else 

SRQ  =  sum([t_delay4  (3+15*i)*maxretries(m4)]); 

DATA  =  0; 

OOSFLAG  =  1 ; 
end 

Q/  ********************************************************** 

/O 
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%  subpackets  corrupted  (SRQ) 

o/  ********************************************************** 

/O 

else 

[SRQ,DATA]=srq2(m1  ,m2,m3,m4,m5,m6,m7,i,OOSFLAG); 
OOSFLAG  =  0; 
end 
break 
end 
end 

else 

DATA  =  data_set(m2); 

OOSFLAG  =  0; 

SRQ  =  0; 
end 


The  function  srq2.m  creates  packets  that  are  retransmitted  upon  unsuccessful 
initial  transmission. 


function  [SRQ,DATA]=srq2(m1 , m2, m3, m4,m5,m6,m7,i, OOSFLAG) 


[number_modems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq; 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5)); 

srqcount=1 ; 

if  OOSFLAG 

baudrate  =  baudrate2(m7); 
else 

baudrate  =  baudratel  (ml); 
end 
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while  srqcount  <=  maxretries(m4) 
dice4=rand(1); 

if  dice4  <  L4(m3) 
srqcount=srqcount+1 ; 
else 
break 
end 


%  in  case  of  more  than  max  SRQ,  the  packet  gets  aborted 

if  srqcount  >  maxretries(m4) 
srqcount=maxretries(m4); 

DATA=0; 

else 

DATA=data_set(m2); 


%  SRQ  calculation  is  not  really  1  on  1  because  multiple  retransmissions 
%  (srqcount)  do  not  necessarily  have  to  be  the  same  length 

SRQ=sum([  srqcount  *  sum([t_delay4  t_ut  t_delay1  t_wu  t_ut... 
i*L_sp(m5)*8/baudrate] )]); 


The  function  meml.m  can  be  compared  to  srql.m  and  handles  retransmissions 
in  case  of  T3A. 


function  [SRQ,DSRQ]=mem1  (ml  ,m2,m3,m4,m5,m6,m7) 

[numberjnodems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq; 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5)); 

dice2=rand(1); 

for  i=1  :(N_sp(m5)) 

if  ( (dice2<(i/N_sp(m5)))  &  (dice2>=(i-1)/N_sp(m5)) ) 
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SRQ  =  sum([t_delay4  t_ut  i*L_sp(m5)*8/baudrate1  (ml)]); 
break 
end 
end 

dice1=rand(1); 

if  ((dice1<L2(m3))  &  (dice1>=L3(m3))) 

DSRQ  =  0; 
else 

DSRQ  =  data_set(m2); 
end 


The  function  mem2.m  handles  retransmissions  in  case  packet-out-of-sequence  for 


T3A. 


function  [OOS,DOOS]=mem2(m1  ,m2,m3,m4,m5,m6,m7) 

[number_modems  t_wu  t_acq  d_ut  d_crc  d_nw  t  delayl  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq; 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5)); 

OOS  =  sum([t_delay4  t_ut ... 

(data_set(m2)+N_sp(m5)*d_crc+d_nw)*8/baudrate2(m7)]); 

dice1=rand(1); 

if  ((dice1<L2)  &  (dice1>=L3(m3))) 


DOOS  =  0; 


else 

DOOS  =  data_set(m2); 
end 
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The  function  ack.m  handles  ACK  messages  for  packet-out-of-sequence  situations. 


function  [ACK]=ack(m1  ,m2,m3,m4,m5,m6,m7,OOSFLAG) 

[numberjnodems  t_wu  t_acq  d_ut  d_crc  d_nw  t_delay1  t_delay2... 
t_delay3  t_delay4  t_delay5  data_set  baudratel  baudrate2  maxretries... 

L_sp  A  T  alfa  LI  L2  L3  L23  L4  maxCTS  maxACK  maxPOLL  maxTOKEN]=INI; 

t_ut=(d_ut+d_crc)*8/baudrate2(m7)+t_acq; 

N_sp(m5)=ceil(data_set(m2)/L_sp(m5)); 

if  OOSFLAG 

baudrate  =  baudrate2(m7); 
else 

baudrate  =  baudratel  (ml); 
end 

ACK  =  t_delay4  +  t_ut; 
diceACK=rand(1); 

if  ((diceACK<L1)  &  (diceACK>=  (L2(m3)+L1)/2  )) 

ACKcount=1; 

while  ACKcount  <  maxACK(m4) 
dice4=rand(1); 
if  dice4  <  L4(m3) 

ACKcount=ACKcount+1 ; 
else 
break 
end 
end 

ACK  =  ACKcount*sum([ACK  t_delay2  (data_set(m2)+N_sp(m5)*d_crc+d_nw)*8/baudrate]); 
end 
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